Instructions from __nodebug__ functions don't have file:line
information even when inlined into no-nodebug functions. As a result,
intrinsics (SSE and other) from <*intrin.h> clang headers _never_
have file:line information.
With this change, an instruction without !dbg metadata gets one from
the call instruction when inlined.
Fixes PR19001.
llvm-svn: 210459
The PowerPC vsumsws instruction, accessed via vec_sums, is defined
architecturally with a big-endian bias, in that the second input vector
and the result always reference big-endian element 3 (little-endian
element 0). For ease of porting, the programmer wants elements 3 in
both cases.
To provide this semantics, for little endian we generate a permute for
the second input vector prior to the vsumsws instruction, and generate
a permute for the result vector following the vsumsws instruction.
The correctness of this code is tested by the new sums.c test added in
a previous patch, as well as the modifications to
builtins-ppc-altivec.c in the present patch.
llvm-svn: 210449
This uncovered something strange. Diagnostics for InlineAsm have source locations
that don't really map to where they are within the .c source file.
llvm-svn: 210440
The PowerPC vector-unpack-high and vector-unpack-low instructions
are defined architecturally with a big-endian bias, in that the vector
element numbering is assumed to be "left to right" regardless of
whether the processor is in big-endian or little-endian mode. This
effectively reverses the meaning of "high" and "low." Such a
definition is unnatural for little-endian code generation.
To facilitate ease of porting, the vec_unpackh and vec_unpackl
interfaces are designed to use natural element ordering, so that
elements are numbered according to little-endian design principles
when code is generated for a little-endian target. The desired
semantics can be achieved by using the opposite instruction for
little-endian mode. That is, when a call to vec_unpackh appears in
the code, a vector-unpack-low is generated, and when a call to
vec_unpackl appears in the code, a vector-unpack-high is generated.
The correctness of this code is tested by the new unpack.c test
added in a previous patch, as well as the modifications to
builtins-ppc-altivec.c in the present patch.
Note that these interfaces were originally incorrectly implemented
when they take a vector pixel argument. This patch corrects this
implementation for both big- and little-endian code generation.
llvm-svn: 210391
Commit r210384 prematurely included changes to the little-endian
implementation of the vec_sum2s interface. This patch modifies
test/CodeGen/builtins-ppc-altivec.c to test those changes.
llvm-svn: 210389
The Altivec builtin test case test/CodeGen/builtins-ppc-altivec.c has
always been executed only for 32-bit PowerPC. These tests are equally
valid for 64-bit PowerPC. This patch updates the test to be run for
three targets: powerpc-unknown-unknown, powerpc64-unknown-unknown,
and powerpc64le-unknown-unknown. The expected code generation changes
for some of the Altivec builtins for little endian, so this patch adds
new CHECK-LE variants to the test for the powerpc64le target.
These tests satisfy the testing requirements for some previous patches
committed over the last couple of days for lib/Headers/altivec.h:
r210279 for vec_perm, r210337 for vec_mul[eo], and r210340 for
vec_pack.
llvm-svn: 210384
This patch adds support for pointer types in global named registers variables.
It'll be lowered as a pair of read/write_register and inttoptr/ptrtoint calls.
Also adds some early checks on types on SemaDecl to avoid the assert.
Tests changed accordingly. (PR19837)
llvm-svn: 210274
These intrinsics are special because they directly take a memory operand (AVX2
adds the register counterparts). Typically, other non-memop intrinsics take
registers and then it's left to isel to fold memory operands.
In order to LICM intrinsics directly reading memory, we require that no stores
are in the loop (LICM) or that the folded load accesses constant memory
(MachineLICM). When neither is the case we fail to hoist a loop-invariant
broadcast.
We can work around this limitation if we expose the load as a regular load and
then just implement the broadcast using the vector initializer syntax. This
exposes the load to LICM and other optimizations.
At the IR level this is translated into a series of insertelements. The
sequence is already recognized as a broadcast so there is no impact on the
quality of codegen.
_mm256_broadcast_pd and _mm256_broadcast_ps are not updated by this patch
because right now we lack the DAG-combiner smartness to recover the broadcast
instructions. This will be tackled in a follow-on.
There will be completing changes on the LLVM side to remove the LLVM
intrinsics and to auto-upgrade bitcode files.
Fixes <rdar://problem/16494520>
llvm-svn: 209846
Clang knows about the sanitizer blacklist and it makes no sense to
add global to the list of llvm.asan.dynamically_initialized_globals if it
will be blacklisted in the instrumentation pass anyway. Instead, we should
do as much blacklisting as possible (if not all) in the frontend.
llvm-svn: 209789
I opened a discussion on cfe-commits. Ideally we've got a few things
that need to happen. CompilerRT should probably have blacklists tests.
Asan should probably not depend on that specific field.
llvm-svn: 209766
That small change, although it looked harmless, it made emitting the LValue
on the PHI node without the proper cast. Reverting it fixes PR19841.
llvm-svn: 209663
A few (mostly CodeGen) parts of Clang were tightly coupled to the
AArch64 backend. Now that it's gone, they will not even compile.
I've also deduplicated RUN lines in many of the AArch64 tests. This
might improve "make check-all" time noticably: some of those NEON
tests were monsters.
llvm-svn: 209578
I forgot to fix this one in r209145. We use these flags on dllimport tests
to make sure we emit code for available_externaly functions and don't inline
the IR.
llvm-svn: 209564
Summary:
Previously, you could not specify the original file name when passing a preprocessed file into the compiler
Now you can use 'clang -Xclang -main-file-name -Xclang <original file name> ...'
Or 'clang -cc1 -main-file-name <original file name> ...'
llvm-svn: 209503
This is a testcase for r209227, a change in LLVM that automatically sets
visibility to default when the linkage is changed to local (rather than
asserting).
What this testcase triggers is hard to reproduce otherwise: the
`GlobalValue` is created (with non-local linkage), the visibility is set
to hidden, and then the linkage is set to local.
PR19760
llvm-svn: 209228
This is a GNU attribute that causes calls within the attributed function
to be inlined where possible. It is implemented by giving such calls the
alwaysinline attribute.
Differential Revision: http://reviews.llvm.org/D3816
llvm-svn: 209217
behavior on mismatch. The AutoUpgrader will drop incompatible debug info
any way and also emit a warning diagnostic for it.
rdar://problem/16926122
llvm-svn: 209182
This is a GNU attribute that allows split stacks to be turned off on a
per-function basis.
Differential Revision: http://reviews.llvm.org/D3817
llvm-svn: 209167
This patch implements global named registers in Clang, lowering to the just
created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue
had to be created (Register), which just adds support to carry the metadata
node containing the name of the register. Two new methods to emit loads and
stores interoperate with another to emit the named metadata node.
No guarantees are being made and only non-allocatable global variable named
registers are being supported. Local named register support is unchanged.
llvm-svn: 209149
When we were padding a struct to avoid splitting it between registers and
the stack, we were throwing away the type which the argument should be coerced
to.
llvm-svn: 209122
Now that llvm cannot represent alias cycles, we have to diagnose erros just
before trying to close the cycle. This degrades the errors a bit. The real
solution is what it was before: if we want to provide good errors for these
cases, we have to be able to find a clang level decl given a mangled name
and produce the error from Sema.
llvm-svn: 209008
This looks like the right way for this check to work, but there is
another semi-obvious bug, I would think: why is CurLoc not zero'd out
between functions? The possibility for it to bleed between them seems
problematic. (& indeed I caused tests to fail when I fixed this a
different way, by setting CurLoc to SourceLocation() and the end of
EmitFunctionEnd... )
The changes to debug-info-blocks.m are due to a mismatch between the
source manager's file naming and CGDebugInfo's default handling when no
-main-file-name is specified. This actually reveals somewhat of a bug in
the debug info when using source files from standard in, too. See the
comment in CGDebugInfo::CreateCompileUnit for more details.
llvm-svn: 208742
Summary:
Most of the clang header patch by Simon Pilgrim @ SCEE.
Also fixed (or added) clang tests for these intrinsics.
LLVM tests to make sure we get the blend instruction out of these
shufflevectors are at http://reviews.llvm.org/D3600
Reviewers: eli.friedman, craig.topper, rafael
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3601
llvm-svn: 208664
Add ARM support for dllexport and dllimport attributes. This is a relatively
conservative change. The alternative is to entirely drop the architecture
requirement. The dllimport and dllexport attributes are not restricted to any
architecture, simply to platforms that support this attribute (currently
Windows).
llvm-svn: 208486
Evgeniy Stepanov