| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`#pragma comment` was handled by Sema calling a function on ASTConsumer, and
CodeGen then implementing this function and writing things to its output.
Instead, introduce a PragmaCommentDecl AST node and hang one off the
TranslationUnitDecl for every `#pragma comment` line, and then use the regular
serialization machinery. (Since PragmaCommentDecl has codegen relevance, it's
eagerly deserialized.)
http://reviews.llvm.org/D17799
llvm-svn: 262493
|
|
|
|
| |
llvm-svn: 262492
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise users get messages from CheckAtomic about missing libatomic
instead of a sensible message that says "use GCC 4.7 or newer".
I structured the change along the lines of HandleLLVMStdlib.cmake, so
that the standalone build of Clang still gets the compiler version
check.
Reviewers: beanz
Differential Revision: http://reviews.llvm.org/D17789
llvm-svn: 262491
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parts of the AA interface out of the base class of every single AA
result object.
Because this logic reformulates the query in terms of some other aspect
of the API, it would easily cause O(n^2) query patterns in alias
analysis. These could in turn be magnified further based on the number
of call arguments, and then further based on the number of AA queries
made for a particular call. This ended up causing problems for Rust that
were actually noticable enough to get a bug (PR26564) and probably other
places as well.
When originally re-working the AA infrastructure, the desire was to
regularize the pattern of refinement without losing any generality.
While I think it was successful, that is clearly proving to be too
costly. And the cost is needless: we gain no actual improvement for this
generality of making a direct query to tbaa actually be able to
re-use some other alias analysis's refinement logic for one of the other
APIs, or some such. In short, this is entirely wasted work.
To the extent possible, delegation to other API surfaces should be done
at the aggregation layer so that we can avoid re-walking the
aggregation. In fact, this significantly simplifies the logic as we no
longer need to smuggle the aggregation layer into each alias analysis
(or the TargetLibraryInfo into each alias analysis just so we can form
argument memory locations!).
However, we also have some delegation logic inside of BasicAA and some
of it even makes sense. When the delegation logic is baking in specific
knowledge of aliasing properties of the LLVM IR, as opposed to simply
reformulating the query to utilize a different alias analysis interface
entry point, it makes a lot of sense to restrict that logic to
a different layer such as BasicAA. So one aspect of the delegation that
was in every AA base class is that when we don't have operand bundles,
we re-use function AA results as a fallback for callsite alias results.
This relies on the IR properties of calls and functions w.r.t. aliasing,
and so seems a better fit to BasicAA. I've lifted the logic up to that
point where it seems to be a natural fit. This still does a bit of
redundant work (we query function attributes twice, once via the
callsite and once via the function AA query) but it is *exactly* twice
here, no more.
The end result is that all of the delegation logic is hoisted out of the
base class and into either the aggregation layer when it is a pure
retargeting to a different API surface, or into BasicAA when it relies
on the IR's aliasing properties. This should fix the quadratic query
pattern reported in PR26564, although I don't have a stand-alone test
case to reproduce it.
It also seems general goodness. Now the numerous AAs that don't need
target library info don't carry it around and depend on it. I think
I can even rip out the general access to the aggregation layer and only
expose that in BasicAA as it is the only place where we re-query in that
manner.
However, this is a non-trivial change to the AA infrastructure so I want
to get some additional eyes on this before it lands. Sadly, it can't
wait long because we should really cherry pick this into 3.8 if we're
going to go this route.
Differential Revision: http://reviews.llvm.org/D17329
llvm-svn: 262490
|
|
|
|
| |
llvm-svn: 262489
|
|
|
|
|
|
|
|
|
|
|
| |
The LNT test suite with -polly-process-unprofitable
-polly-position=before-vectorizer currenty fails 59 tests. With this
barrier added, only 16 keep failing. This is probably because Polly's
code generation currently does not correctly preserve all analyses it
promised to preserve. Temporarily add this barrier until further
investigation.
llvm-svn: 262488
|
|
|
|
|
|
|
| |
location as we cannot assume the location of the input file to be
writable.
llvm-svn: 262487
|
|
|
|
|
|
| |
elements from one of the inputs of a binary shuffle (punpcklbw)
llvm-svn: 262486
|
|
|
|
| |
llvm-svn: 262485
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IncludeInserter handles macro header file.
Summary: Also Fixes PR24749.
Reviewers: alexfh
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D17805
llvm-svn: 262484
|
|
|
|
|
|
|
|
|
| |
Incremented the pc for each architecture in accordance with StackTrace:GetPreviousInstructionPC
Reviewers: samsonov, dvyukov
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential: http://reviews.llvm.org/D17802
llvm-svn: 262483
|
|
|
|
|
|
|
|
|
| |
Previously we were using thumbv7 and armv8.1a what ended up showing a
few undefined instruction when disassembling code. This CL update the
architectures used to armv8.2a and thumbv8.2a (newest available) so we
display all instruction in the disassambly.
llvm-svn: 262482
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17706
llvm-svn: 262481
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17705
llvm-svn: 262480
|
|
|
|
|
|
| |
This reverts commit r262476, as it broken the AArch64 VMA42 buildbot.
llvm-svn: 262479
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a number of useful lowering strategies for VBROADCAST instructions (both from memory and register element 0) which the 128-bit form of the MOVDDUP instruction can make use of.
This patch tweaks lowerVectorShuffleAsBroadcast to enable it to broadcast 2f64 args using MOVDDUP as well.
It does require a slight tweak to the lowerVectorShuffleAsBroadcast mechanism as the existing MOVDDUP lowering uses isShuffleEquivalent which can match binary shuffles that can lower to (unary) broadcasts.
Differential Revision: http://reviews.llvm.org/D17680
llvm-svn: 262478
|
|
|
|
|
|
|
|
| |
fields"
Build failure with clang.
llvm-svn: 262477
|
|
|
|
|
|
|
|
| |
by avoiding potential races when scanning stdout and stderr output.
Patch by Maxim Kuvyrkov.
llvm-svn: 262476
|
|
|
|
|
|
|
|
| |
assembler."
Build failure with clang.
llvm-svn: 262475
|
|
|
|
|
|
|
|
|
|
| |
complementary patch to table-driven amd_kernel_code_t field parser/printer utility. lit tests passed.
Patch by: Valery Pykhtin
Differential Revision: http://reviews.llvm.org/D17151
llvm-svn: 262474
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is going to be used in .hsatext disassembler and can be used
in current assembler parser (lit tests passed on parsing).
Code using this helpers isn't included in this patch.
Benefits:
unified approach
fast field name lookup on parsing
Later I would like to enhance some of the field naming/syntax using this code.
Patch by: Valery Pykhtin
Differential Revision: http://reviews.llvm.org/D17150
llvm-svn: 262473
|
|
|
|
|
|
|
|
| |
- unused sigaction/setitimer result (used in assert)
- unchecked fscanf return value
- signed/unsigned comparison
llvm-svn: 262472
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17699
llvm-svn: 262471
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: alexfh
Subscribers: jbcoe, cfe-commits
Differential Revision: http://reviews.llvm.org/D17756
llvm-svn: 262470
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17783
llvm-svn: 262469
|
|
|
|
|
|
| |
VEX prefix. The operand is always a register. NFC
llvm-svn: 262468
|
|
|
|
|
|
| |
how VEX prefix handling does.
llvm-svn: 262467
|
|
|
|
|
|
|
|
|
|
|
| |
Sema allows max values up to 2**28, use unsigned instead of unsiged
short to hold values that large.
Differential Revision: http://reviews.llvm.org/D17248
Patch by Don Hinton!
llvm-svn: 262466
|
|
|
|
|
|
|
|
|
|
|
| |
We modeled the RDFLAGS{32,64} operations as "using" {E,R}FLAGS.
While technically correct, this is not be desirable for folks who want
to examine aspects of the FLAGS register which are not related to
computation like whether or not CPUID is a valid instruction.
Differential Revision: http://reviews.llvm.org/D17782
llvm-svn: 262465
|
|
|
|
| |
llvm-svn: 262464
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17794
llvm-svn: 262463
|
|
|
|
|
|
|
|
|
|
| |
encoded in bits 7:4 of the immediate.
For some instructions the register is not the last operand and the immediate handling had to detect this and hardcode the index to find it. It also required CurOp to be pointing at the last operand handled in the Form switch whereas for any instruction it would be pointing at the next operand.
Now we just capture the value in the Form switch when we know exactly where it is and the CurOp pointer can behave normally.
llvm-svn: 262462
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch fixes two related problems:
- If CIE augmentation string has 'L' token the CIE contains a byte
defines LSDA encoding. We should skip this byte in `getFdeEncoding`
routine. Before this fix we do not skip it and if the next token
is 'R' treat this byte as FDE encoding.
- FDE encoding format has separate flags e.g. DW_EH_PE_pcrel for
definition of relative pointers. We should add .eh_frame address to
the PC value iif the DW_EH_PE_pcrel is specified.
http://www.airs.com/blog/archives/460
There is one more not fixed problem in this code. If PC value is encoded
using signed relative format e.g. DW_EH_PE_sdata4 | DW_EH_PE_pcrel we
should sign extend result of read32 to perform calculation correctly.
I am going to fix that in a separate patch.
Differential Revision: http://reviews.llvm.org/D17733
llvm-svn: 262461
|
|
|
|
|
|
|
|
| |
OpenMP 4.5 allows to privatize non-static data members of current class
in non-static member functions. Patch supports codegen for non-static
data members in 'reduction' clauses.
llvm-svn: 262460
|
|
|
|
| |
llvm-svn: 262459
|
|
|
|
|
|
| |
respectively should reduce size tiny bit. NFC
llvm-svn: 262458
|
|
|
|
|
|
|
|
| |
Fix checking the same instruction twice instead of the
second branch that uses vccz. I don't think this matters
currently because s_branch_vccnz is always used currently.
llvm-svn: 262457
|
|
|
|
| |
llvm-svn: 262456
|
|
|
|
| |
llvm-svn: 262455
|
|
|
|
| |
llvm-svn: 262454
|
|
|
|
| |
llvm-svn: 262453
|
|
|
|
| |
llvm-svn: 262452
|
|
|
|
|
|
|
|
| |
For some reason MSVC seems to think I'm calling getConstant() from a
static context. Try to avoid this issue by explicitly specifying
'this->' (though I'm not confident that this will actually work).
llvm-svn: 262451
|
|
|
|
|
|
| |
other minor fixes.
llvm-svn: 262450
|
|
|
|
| |
llvm-svn: 262449
|
|
|
|
| |
llvm-svn: 262448
|
|
|
|
| |
llvm-svn: 262447
|
|
|
|
| |
llvm-svn: 262446
|
|
|
|
| |
llvm-svn: 262445
|
|
|
|
| |
llvm-svn: 262444
|