| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Aliases in llvm now hold an arbitrary expression.
llvm-svn: 210063
|
| |
|
|
|
|
| |
{extract,insert} vector element instructions.
llvm-svn: 209942
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
(fixes PR19431 - http://llvm.org/bugs/show_bug.cgi?id=19431)
llvm-svn: 209769
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 209726
|
| |
|
|
| |
llvm-svn: 209668
|
| |
|
|
| |
llvm-svn: 209666
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 209596
|
| |
|
|
|
|
| |
This keeps Clang consistent with backend naming conventions.
llvm-svn: 209579
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 209541
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 209465
|
| |
|
|
| |
llvm-svn: 209289
|
| |
|
|
| |
llvm-svn: 209260
|
| |
|
|
| |
llvm-svn: 209255
|
| |
|
|
| |
llvm-svn: 209229
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 209196
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 209180
|
| |
|
|
|
|
|
|
|
| |
Also adding a variable to the test, so release bots match %1.
This should also calm the gdb buildbot.
.
llvm-svn: 209171
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
and requires internal padding
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 is a step towards handling these attributes on classes (PR11170).
Differential Revision: http://reviews.llvm.org/D3772
llvm-svn: 208925
|
| |
|
|
| |
llvm-svn: 208875
|
| |
|
|
| |
llvm-svn: 208868
|
| |
|
|
| |
llvm-svn: 208761
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
current scope has not changed.
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
|
| |
|
|
| |
llvm-svn: 208665
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
registers'). Bots are now pacified.
llvm-svn: 208425
|
| |
|
|
|
|
| |
registers'). This is a followon commit from r208413 which broke the LLVM bots.
llvm-svn: 208422
|
| |
|
|
|
|
|
| |
This is the clang counterpart to 208413, which ensures that Homogeneous
Floating-point Aggregates are passed in consecutive registers on ARM.
llvm-svn: 208417
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
correctly.
Previously we calculated the shift amount based upon DataLayout::getTypeAllocSizeInBits.
This will only work for legal types - types such as i24 that are created as part of
structs for bitfields will return "32" from that function. Change to using
getTypeSizeInBits.
It turns out that AArch64 didn't run across this problem because it always returned
[1 x i64] as the type for a bitfield, whereas ARM64 returns i64 so goes down this
(better, but wrong) codepath.
llvm-svn: 208231
|
| |
|
|
|
|
| |
didn't notice that the generated BE alignment register is now unnamed and is not called '%align_be'.
llvm-svn: 208217
|
| |
|
|
|
|
|
| |
Just because the first "if" didn't fire, doesn't mean we can not have
an HFA in the "else" clause.
llvm-svn: 208216
|
| |
|
|
|
|
|
|
|
|
|
|
| |
ABIArgInfo::getExpandWithPadding
In cases where a struct must, according to the AAPCS, not be split between
general purpose and floating point registers, we use
ABIArgInfo::getExpandWithPadding to add the padding arguments. However,
ExpandWithPadding does not work if the struct contains bitfields, so we
instead must use ABIArgInfo::getDirect.
llvm-svn: 208185
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
preceeds the declaration and initial use.
Reverting r208106 to reapply r208065 with a fix for the regression. The
issue was that the enum tried to be built even if the declaration hadn't
been constructed for debug info - presenting problems for enum templates
and typedefs of enums with names for linkage purposes.
Original commit message:
This regressed a little further 208055 though it was already a little
broken.
While the requiresCompleteType optimization should be implemented here.
Future (possibly near future) work.
llvm-svn: 208114
|
| |
|
|
|
|
|
|
|
|
|
| |
the declaration and initial use."
This is breaking the compiler-rt build. Reverting while I
investigate/fix.
This reverts commit r208065.
llvm-svn: 208106
|
| |
|
|
|
|
|
|
|
|
|
|
| |
declaration and initial use.
This regressed a little further 208055 though it was already a little
broken.
While the requiresCompleteType optimization should be implemented here.
Future (possibly near future) work.
llvm-svn: 208065
|
| |
|
|
|
|
| |
This is in addition to the existing support for typedefs.
llvm-svn: 208053
|