| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 264299
|
|
|
|
|
|
|
|
|
|
|
|
| |
KTEST instruction may be used instead of TEST in this case:
%int_sel3 = bitcast <8 x i1> %sel3 to i8
%res = icmp eq i8 %int_sel3, zeroinitializer
br i1 %res, label %L2, label %L1
Differential Revision: http://reviews.llvm.org/D18444
llvm-svn: 264298
|
|
|
|
|
|
| |
complain.
llvm-svn: 264297
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the operation's type has been promoted during type legalization, we
need to account for the fact that the high bits of the comparison
operand are likely unspecified.
The LHS is usually zero-extended, but MIPS sign extends it, so we have
to be slightly careful.
Patch by Simon Dardis.
llvm-svn: 264296
|
|
|
|
|
|
| |
Patch By: Sonny Jiang
llvm-svn: 264295
|
|
|
|
| |
llvm-svn: 264294
|
|
|
|
| |
llvm-svn: 264293
|
|
|
|
|
|
|
| |
With this I think that now llvm-link, lld and the gold plugin should
agree on which symbol is kept.
llvm-svn: 264292
|
|
|
|
| |
llvm-svn: 264291
|
|
|
|
| |
llvm-svn: 264290
|
|
|
|
|
|
|
|
|
|
|
| |
After comdat processing, the symbols still go through regular symbol
resolution.
We were not doing it for linkonce symbols since they are lazy linked.
This fixes pr27044.
llvm-svn: 264288
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Reviewers: vkalintiris
Subscribers: llvm-commits, dsanders
Differential Revision: http://reviews.llvm.org/D18177
llvm-svn: 264287
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Some target lowerings of FP_TO_FP16, for instance ARM's vcvtb.f16.f32
instruction, do not guarantee that the top 16 bits are zeroed out.
Remove the unsafe AssertZext and add tests to exercise this.
Reviewers: jmolloy, sbaranga, kristof.beyls, aadg
Subscribers: llvm-commits, srhines, aemerson
Differential Revision: http://reviews.llvm.org/D18426
llvm-svn: 264285
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch corresponds to review:
http://reviews.llvm.org/D17711
It disables direct moves on these operations in 32-bit mode since the patterns
assume 64-bit registers. The final patch is slightly different from the
Phabricator review as the bitcast operations needed to be disabled in 32-bit
mode as well. This fixes PR26617.
llvm-svn: 264282
|
|
|
|
|
|
|
|
|
|
| |
LLVM debug info."
After fixing PR26942 (the fix is included in this commit).
Differential Revision: http://reviews.llvm.org/D18350
llvm-svn: 264280
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Reviewers: vkalintiris
Subscribers: llvm-commits, dsanders
Differential Revision: http://reviews.llvm.org/D18148
llvm-svn: 264279
|
|
|
|
|
|
|
|
| |
This patch begins adding support for lowering to the XOP VPPERM instruction - adding the X86ISD::VPPERM opcode.
Differential Revision: http://reviews.llvm.org/D18189
llvm-svn: 264260
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In particular, make the cnMIPS predicates much more obvious and prefer
def ... : ... {
let Foo = bar;
}
over:
let Foo = bar in
def ... : ...;
Reviewers: vkalintiris
Subscribers: dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D18354
llvm-svn: 264258
|
|
|
|
| |
llvm-svn: 264255
|
|
|
|
|
|
| |
I committed the test changes successfully but managed to miss the actual code change! (lack of git -a)
llvm-svn: 264249
|
|
|
|
|
|
|
|
| |
DDIVU and DMODU instructions
Differential Revision: http://reviews.llvm.org/D17137
llvm-svn: 264248
|
|
|
|
|
|
| |
Correctly add a space between the address and size when outputting in posix mode (-P).
llvm-svn: 264247
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17328
llvm-svn: 264246
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17068
llvm-svn: 264245
|
|
|
|
| |
llvm-svn: 264244
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to only allow SCEVAddRecExpr for pointer expressions in order to
be able to compute the bounds. However this is also trivially possible
for loop-invariant addresses (scUnknown) since then the bounds are the
address itself.
Interestingly, we used allow this for the special case when the
loop-invariant address happens to also be an SCEVAddRecExpr (in an outer
loop).
There are a couple more loops that are vectorized in SPEC after this.
My guess is that the main reason we don't see more because for example a
loop-invariant load is vectorized into a splat vector with several
vector-inserts. This is likely to make the vectorization unprofitable.
I.e. we don't notice that a later LICM will move all of this out of the
loop so the cost estimate should really be 0.
llvm-svn: 264243
|
|
|
|
|
|
| |
More utilities to help with std::error_code -> Error transitions.
llvm-svn: 264238
|
|
|
|
|
|
| |
use _Exit instead of exit in the timeout callback)
llvm-svn: 264237
|
|
|
|
| |
llvm-svn: 264230
|
|
|
|
|
|
| |
volatiles are not combined
llvm-svn: 264225
|
|
|
|
|
|
|
|
|
|
| |
We need the "return address" of a noreturn call to be within the
bounds of the calling function; TrapUnreachable turns 'unreachable'
into a 'ud2' instruction, which has that desired effect.
Differential Revision: http://reviews.llvm.org/D18414
llvm-svn: 264224
|
|
|
|
|
|
|
|
|
|
|
| |
If not for lazy linking of linkonce GVs, comdats are just a
preprocessing before symbol resolution.
Lazy linking complicates it since when we pick a visible member of
comdat, we have to make sure the rest of it passes symbol resolution
too.
llvm-svn: 264223
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18418
llvm-svn: 264222
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a temporary crutch to enable code that currently uses std::error_code
to be incrementally moved over to Error. Requiring all Error instances be
convertible enables clients to call errorToErrorCode on any error (not just
ECErrors created by conversion *from* an error_code).
This patch also moves code for Error from ErrorHandling.cpp into a new
Error.cpp file.
llvm-svn: 264221
|
|
|
|
| |
llvm-svn: 264219
|
|
|
|
|
|
|
| |
There is no benefit to these since materializing the constant 1
requires the same number of instructions as materializing uint_max
llvm-svn: 264215
|
|
|
|
| |
llvm-svn: 264214
|
|
|
|
|
|
|
|
| |
Summary: Reply to http://reviews.llvm.org/D18341
Differential Revision: http://reviews.llvm.org/D18406
llvm-svn: 264213
|
|
|
|
|
|
|
| |
This should fix the docs build.
Spotted by spstarr, thanks!
llvm-svn: 264209
|
|
|
|
| |
llvm-svn: 264208
|
|
|
|
|
|
|
|
|
|
|
| |
The BumpPtrAllocator currently doesn't handle zero length allocations well.
The discussion for how to fix that is ongoing. However, there's no need
for StringRef::copy to actually allocate anything here anyway, so just
return StringRef() when we get a zero length copy.
Reviewed by David Blaikie
llvm-svn: 264201
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Strengthen tests of storing frame indices.
Right now this just creates irrelevant scheduling changes.
We don't want to have multiple frame index operands
on an instruction. There seem to be various assumptions
that at least the same frame index will not appear twice
in the LocalStackSlotAllocation pass.
There's no reason to have this happen, and it just
makes it easy to introduce bugs where the immediate
offset is appplied to the storing instruction when it should
really be applied to the value being stored as a separate
add.
This might not be sufficient. It might still be problematic
to have an add fi, fi situation, but that's even less unlikely
to happen in real code.
llvm-svn: 264200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, AnalyzeBranch() fails non-equality comparison between floating points
on X86 (see https://llvm.org/bugs/show_bug.cgi?id=23875). This is because this
function can modify the branch by reversing the conditional jump and removing
unconditional jump if there is a proper fall-through. However, in the case of
non-equality comparison between floating points, this can turn the branch
"unanalyzable". Consider the following case:
jne.BB1
jp.BB1
jmp.BB2
.BB1:
...
.BB2:
...
AnalyzeBranch() will reverse "jp .BB1" to "jnp .BB2" and then "jmp .BB2" will be
removed:
jne.BB1
jnp.BB2
.BB1:
...
.BB2:
...
However, AnalyzeBranch() cannot analyze this branch anymore as there are two
conditional jumps with different targets. This may disable some optimizations
like block-placement: in this case the fall-through behavior is enforced even if
the fall-through block is very cold, which is suboptimal.
Actually this optimization is also done in block-placement pass, which means we
can remove this optimization from AnalyzeBranch(). However, currently
X86::COND_NE_OR_P and X86::COND_NP_OR_E are not reversible: there is no defined
negation conditions for them.
In order to reverse them, this patch defines two new CondCode X86::COND_E_AND_NP
and X86::COND_P_AND_NE. It also defines how to synthesize instructions for them.
Here only the second conditional jump is reversed. This is valid as we only need
them to do this "unconditional jump removal" optimization.
Differential Revision: http://reviews.llvm.org/D11393
llvm-svn: 264199
|
|
|
|
|
|
|
| |
the cause of the tools/llvm-objdump/X86/macho-symbolized-disassembly.test
crashing on linux. Either way clearly incorrect code.
llvm-svn: 264198
|
|
|
|
|
|
|
|
|
| |
The goal is to enhance this script to be used with opt and clang:
Group all of the regexes together, so it's easier to see what's going on.
This will make it easier to break main() up into pieces too.
Also, note that some of the regexes are for x86-specific asm.
llvm-svn: 264197
|
|
|
|
|
|
| |
to getSymbolType().
llvm-svn: 264194
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a comdat is dropped, all symbols in it are dropped.
If a comdat is kept, the symbols survive to pass regular symbol
resolution.
With this patch we do that for all global symbols.
The added test is a copy of test/tools/gold/X86/comdat.ll that we now
pass.
llvm-svn: 264192
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the test suite. While this is not really an interesting tool and option to run
on a Mach-O file to show the symbol table in a generic libObject format
it shouldn’t crash.
The reason for the crash was in MachOObjectFile::getSymbolType() when it was
calling MachOObjectFile::getSymbolSection() without checking its return value
for the error case.
What makes this fix require a fair bit of diffs is that the method getSymbolType() is
in the class ObjectFile defined without an ErrorOr<> so I needed to add that all
the sub classes. And all of the uses needed to be updated and the return value
needed to be checked for the error case.
The MachOObjectFile version of getSymbolType() “can” get an error in trying to
come up with the libObject’s internal SymbolRef::Type when the Mach-O symbol
symbol type is an N_SECT type because the code is trying to select from the
SymbolRef::ST_Data or SymbolRef::ST_Function values for the SymbolRef::Type.
And it needs the Mach-O section to use isData() and isBSS to determine if
it will return SymbolRef::ST_Data.
One other possible fix I considered is to simply return SymbolRef::ST_Other
when MachOObjectFile::getSymbolSection() returned an error. But since in
the past when I did such changes that “ate an error in the libObject code” I
was asked instead to push the error out of the libObject code I chose not
to implement the fix this way.
As currently written both the COFF and ELF versions of getSymbolType()
can’t get an error. But if isReservedSectionNumber() wanted to check for
the two known negative values rather than allowing all negative values or
the code wanted to add the same check as in getSymbolAddress() to use
getSection() and check for the error then these versions of getSymbolType()
could return errors.
At the end of the day the error printed now is the generic “Invalid data was
encountered while parsing the file” for object_error::parse_failed. In the
future when we thread Lang’s new TypedError for recoverable error handling
though libObject this will improve. And where the added // Diagnostic(…
comment is, it would be changed to produce and error message
like “bad section index (42) for symbol at index 8” for this case.
llvm-svn: 264187
|
|
|
|
|
|
|
|
|
|
| |
This should be hoisted further up so it can be used in DAGCombiner and other backends,
but I'm limiting the scope in the interest of patch minimalism.
It's not quite NFC because some of the replaced code was using an 'if' check rather
than a 'while' loop, so those cases would only look through a single bitcast.
llvm-svn: 264186
|
|
|
|
| |
llvm-svn: 264185
|