| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Identical to SELECT, just with different operand numbers.
llvm-svn: 246366
|
| |
|
|
| |
llvm-svn: 246365
|
| |
|
|
| |
llvm-svn: 246364
|
| |
|
|
|
|
|
|
| |
(Re)added debug codegen test for F16C, FMA4, XOP + 3DNow! intrinsics
Part of PR24590
llvm-svn: 246363
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D12436
llvm-svn: 246362
|
| |
|
|
|
|
| |
I have no idea how I missed this in my internal testing. Just no idea. Sorry for the bot-armageddon.
llvm-svn: 246361
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is especially visible in softfp mode, for example in the implementation of libm fabs/fneg functions. If we have:
%1 = vmovdrr r0, r1
%2 = fabs %1
then move the fabs before the vmovdrr:
%1 = and r1, #0x7FFFFFFF
%2 = vmovdrr r0, r1
This is never a lose, and could be a serious win because the vmovdrr may be followed by a vmovrrd, which would enable us to remove the conversion into FPRs completely.
We already do this for f32, but not for f64. Tests are added for both.
llvm-svn: 246360
|
| |
|
|
|
|
|
|
|
|
| |
We cannot tell if an object is past-the-end if its type is incomplete.
Zero sized objects satisfy past-the-end criteria and our object might
turn out to be such an object.
This fixes PR24622.
llvm-svn: 246359
|
| |
|
|
|
|
|
|
|
|
| |
The VOP3 encoding of these allows any SGPR pair for the i1
output, but this was forced before to always use vcc.
This doesn't yet try to use this, but does add the operand
to the definitions so the main change is adding vcc to the
output of the VOP2 encoding.
llvm-svn: 246358
|
| |
|
|
| |
llvm-svn: 246357
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Without a memory operand, mayLoad or mayStore instructions
are treated as hasUnorderedMemRef, which results in much worse
scheduling.
We really should have a verifier check that any
non-side effecting mayLoad or mayStore has a memory operand.
There are a few instructions (interp and images) which I'm
not sure what / where to add these.
llvm-svn: 246356
|
| |
|
|
| |
llvm-svn: 246355
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We were assuming tha if the use operand had a sub-register that
the immediate was 64-bits, but this was breaking the case of
folding a 64-bit immediate into another 64-bit instruction.
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D12255
llvm-svn: 246354
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D12254
llvm-svn: 246353
|
| |
|
|
|
|
|
|
| |
for "native""
Wrong assumption. Consider --host=x86_64-linux --target=(i686|x86_64)-win32. See also r193459.
llvm-svn: 246352
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm working on adding !dbg attachments to functions (PR23367), which
we'll use to determine the canonical subprogram for a function (instead
of the `subprograms:` array in the compile units). This updates a few
old tests in preparation.
Transforms/Mem2Reg/ConvertDebugInfo2.ll had an old-style grep+count
based test that would start to fail because I've added an extra line
with `!dbg`. Instead, explicitly `CHECK` for what I think the test
actually cares about.
All three testcases have subprograms with a valid `function:` reference
-- which means my upgrade script will add a `!dbg` attachment -- but
that aren't referenced from any compile unit. I suspect these testcases
were handreduced over-zealously (or have bitrotted?). Add a reference
from the compile unit so that upcoming Verifier checks won't fail here.
llvm-svn: 246351
|
| |
|
|
|
|
|
|
| |
backend to work.
Differential Revision: http://reviews.llvm.org/D12454
llvm-svn: 246350
|
| |
|
|
|
|
|
|
|
| |
This fixes PR24621 and matches what we do for `DILocation`. Although
the limit seems somewhat artificial, there are places in the backend
that also assume 16-bit columns, so we may as well just be consistent
about the limits.
llvm-svn: 246349
|
| |
|
|
| |
llvm-svn: 246348
|
| |
|
|
|
|
|
| |
whether it can ever produce a constant expression in the case where it has a
void return type and no return statements.
llvm-svn: 246347
|
| |
|
|
| |
llvm-svn: 246346
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
region.
Change the analyzer's modeling of memcpy to be more precise when copying into fixed-size
array fields. With this change, instead of invalidating the entire containing region the
analyzer now invalidates only offsets for the array itself when it can show that the
memcpy stays within the bounds of the array.
This addresses false positive memory leak warnings of the kind reported by
krzysztof in https://llvm.org/bugs/show_bug.cgi?id=22954
A patch by Pierre Gousseau!
Differential Revision: http://reviews.llvm.org/D11832
llvm-svn: 246345
|
| |
|
|
|
|
| |
AArch64 bot.
llvm-svn: 246344
|
| |
|
|
| |
llvm-svn: 246343
|
| |
|
|
|
|
|
|
|
| |
This is exposed via a new flag /opt:lldltojobs=N, where N is the number of
code generation threads.
Differential Revision: http://reviews.llvm.org/D12309
llvm-svn: 246342
|
| |
|
|
|
|
|
|
|
|
| |
I ran the script from r246327 and it touched all the right files;
committing now to hopefully right the bots, but if my check-polly
doesn't come back clean I'll keep looking.
http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/33648
llvm-svn: 246341
|
| |
|
|
| |
llvm-svn: 246340
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add `Function::setSubprogram()` and `Function::getSubprogram()`,
convenience methods to forward to `setMetadata()` and `getMetadata()`,
respectively, and deal in `DISubprogram` instead of `MDNode`.
Also add a verifier check to enforce that `!dbg` attachments are always
subprograms.
Originally (when I had the llvm-dev discussion back in April) I thought
I'd store a pointer directly on `llvm::Function` for these attachments
-- we frequently have debug info, and that's much cheaper than using map
in the context if there are no other function-level attachments -- but
for now I'm just using the generic infrastructure. Let's add the extra
complexity only if this shows up in a profile.
llvm-svn: 246339
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functions when safe (PR24593)
This patch does two things:
1) Don't error about dllimport/export on thread-local static local variables.
We put those attributes on static locals in dllimport/export functions
implicitly in case the function gets inlined. Now, for TLS variables this
is a problem because we can't import such variables, but it's a benign
problem becase:
2) Make sure we never inline a dllimport function TLS static locals. In fact,
never inline a dllimport function that references a non-imported function
or variable (because these are not defined in the importing library). This
seems to match MSVC's behaviour.
Differential Revision: http://reviews.llvm.org/D12422
llvm-svn: 246338
|
| |
|
|
|
|
| |
and 64-bit MIPS ABIs
llvm-svn: 246337
|
| |
|
|
|
|
| |
elf32btsmipn32/elf32ltsmipn32
llvm-svn: 246336
|
| |
|
|
|
|
|
| |
Now it is possible to have mips-linux-gnu-ld executable and link MIPS 64-bit
little-endian binaries providing -melf64ltsmip command line argument.
llvm-svn: 246335
|
| |
|
|
| |
llvm-svn: 246334
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the DWARF backend requires that subprograms have a type, and
the type is ignored if it has an empty type array. The long term
direction here -- see PR23079 -- is instead to skip the type entirely if
there's no valid type.
It turns out we have cases in tree of missing types on subprograms, but
since they're not referenced by compile units, the backend never crashes
on them. One option would be to add a Verifier check that subprograms
have types, and fix the bitrot. However, this is a fair bit of churn
(20-30 testcases) that would be reversed anyway by PR23079.
I found this inconsistency because of a WIP patch and upgrade script for
PR23367 that started crashing on test/DebugInfo/2010-10-01-crash.ll.
This commit updates the testcase to reference the subprogram from the
compile unit, and fixes the resulting crash (in line with the direction
of PR23079). This also updates `DIBuilder` to stop assuming a non-null
pointer for the subroutine types.
llvm-svn: 246333
|
| |
|
|
|
|
| |
For now this just recognizes the special section number.
llvm-svn: 246332
|
| |
|
|
|
|
|
|
|
| |
This reverts isSafeToSpeculativelyExecute's use of ReadNone until we
split ReadNone into two pieces: one attribute which reasons about how
the function reasons about memory and another attribute which determines
how it may be speculated, CSE'd, trap, etc.
llvm-svn: 246331
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch adds support for tsan on aarch64-linux with 42-bit VMA
(current default config for 64K pagesize kernels). The support is
enabled by defining the SANITIZER_AARCH64_VMA to 42 at build time
for both clang/llvm and compiler-rt. The default VMA is 39 bits.
It also enabled tsan for previous supported VMA (39).
llvm-svn: 246330
|
| |
|
|
| |
llvm-svn: 246329
|
| |
|
|
|
|
| |
Patch by Than McIntosh!
llvm-svn: 246328
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a follow-up to r246098, require `DISubprogram` definitions
(`isDefinition: true`) to be 'distinct'. Specifically, add an assembler
check, a verifier check, and bitcode upgrading logic to combat testcase
bitrot after the `DIBuilder` change.
While working on the testcases, I realized that
test/Linker/subprogram-linkonce-weak-odr.ll isn't relevant anymore. Its
purpose was to check for a corner case in PR22792 where two subprogram
definitions match exactly and share the same metadata node. The new
verifier check, requiring that subprogram definitions are 'distinct',
precludes that possibility.
I updated almost all the IR with the following script:
git grep -l -E -e '= !DISubprogram\(.* isDefinition: true' |
grep -v test/Bitcode |
xargs sed -i '' -e 's/= \(!DISubprogram(.*, isDefinition: true\)/= distinct \1/'
Likely some variant of would work for out-of-tree testcases.
llvm-svn: 246327
|
| |
|
|
|
|
|
| |
On ELF being weak is independent of what we call the kind of the symbol. So
this also makes the code simpler.
llvm-svn: 246326
|
| |
|
|
| |
llvm-svn: 246325
|
| |
|
|
| |
llvm-svn: 246324
|
| |
|
|
|
|
| |
This reverts commit r246223, as it broke all ARM/AArch64 bots.
llvm-svn: 246323
|
| |
|
|
| |
llvm-svn: 246322
|
| |
|
|
|
|
| |
This reverts commit r246211, as it broke all ARM/AArch64 bots.
llvm-svn: 246321
|
| |
|
|
|
|
| |
This reverts commit r246206, as it broke all ARM/AArch64 bots.
llvm-svn: 246320
|
| |
|
|
|
|
| |
This reverts commit r246204, as it was breaking all ARM/AArch64 bots.
llvm-svn: 246319
|
| |
|
|
|
|
| |
checkers do not require additional testing as the tests will not compile for other languages or modes, or the checkers would never match a valid construct.
llvm-svn: 246318
|
| |
|
|
|
|
|
| |
In r246314 (Removing expand-vars.pl) patch, I forgot to add kmp_config.h.cmake
This patch just adds it.
llvm-svn: 246317
|