| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
This patch implements ALIGN and AUI instructions using mapping.
Differential Revision: http://reviews.llvm.org/D8782
llvm-svn: 237563
|
| |
|
|
|
|
|
|
|
| |
instructions. These intrinsics are comming with rounding mode.
Added intrinsics for MAXSS/D, MINSS/D - with and without sae.
By Asaf Badouh (asaf.badouh@intel.com)
llvm-svn: 237560
|
| |
|
|
| |
llvm-svn: 237559
|
| |
|
|
| |
llvm-svn: 237558
|
| |
|
|
|
|
|
|
| |
instructions from this set
Added encoding tests.
llvm-svn: 237557
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If some commits are happy, and some commits are sad, this is a sad commit. It
is sad because it restricts instruction scheduling to work around a binutils
linker bug, and moreover, one that may never be fixed. On 2012-05-21, GCC was
updated not to produce code triggering this bug, and now we'll do the same...
When resolving an address using the ELF ABI TOC pointer, two relocations are
generally required: one for the high part and one for the low part. Only
the high part generally explicitly depends on r2 (the TOC pointer). And, so,
we might produce code like this:
.Ltmp526:
addis 3, 2, .LC12@toc@ha
.Ltmp1628:
std 2, 40(1)
ld 5, 0(27)
ld 2, 8(27)
ld 11, 16(27)
ld 3, .LC12@toc@l(3)
rldicl 4, 4, 0, 32
mtctr 5
bctrl
ld 2, 40(1)
And there is nothing wrong with this code, as such, but there is a linker bug
in binutils (https://sourceware.org/bugzilla/show_bug.cgi?id=18414) that will
misoptimize this code sequence to this:
nop
std r2,40(r1)
ld r5,0(r27)
ld r2,8(r27)
ld r11,16(r27)
ld r3,-32472(r2)
clrldi r4,r4,32
mtctr r5
bctrl
ld r2,40(r1)
because the linker does not know (and does not check) that the value in r2
changed in between the instruction using the .LC12@toc@ha (TOC-relative)
relocation and the instruction using the .LC12@toc@l(3) relocation.
Because it finds these instructions using the relocations (and not by
scanning the instructions), it has been asserted that there is no good way
to detect the change of r2 in between. As a result, this bug may never be
fixed (i.e. it may become part of the definition of the ABI). GCC was
updated to add extra dependencies on r2 to instructions using the @toc@l
relocations to avoid this problem, and we'll do the same here.
This is done as a separate pass because:
1. These extra r2 dependencies are not really properties of the
instructions, but rather due to a linker bug, and maybe one day we'll be
able to get rid of them when targeting linkers without this bug (and,
thus, keeping the logic centralized here will make that
straightforward).
2. There are ISel-level peephole optimizations that propagate the @toc@l
relocations to some user instructions, and so the exta dependencies do
not apply only to a fixed set of instructions (without undesirable
definition replication).
The test case was reduced with the help of bugpoint, with minimal cleaning. I'm
looking forward to our upcoming MI serialization support, and with that, much
better tests can be created.
llvm-svn: 237556
|
| |
|
|
| |
llvm-svn: 237545
|
| |
|
|
| |
llvm-svn: 237544
|
| |
|
|
|
|
|
|
|
| |
SimplifyDemandedBits was "simplifying" a constant by removing just sign bits.
This caused a canonicalization race between different parts of instcombine.
Fix and regression test added - third time lucky?
llvm-svn: 237539
|
| |
|
|
| |
llvm-svn: 237537
|
| |
|
|
|
|
|
| |
Filling k-reg with all-ones value was wrong,
(i1 1) should switch on only one bit in mask register
llvm-svn: 237536
|
| |
|
|
| |
llvm-svn: 237533
|
| |
|
|
|
|
|
|
| |
The AArch64 LNT bot is unhappy - I've found that the problem is in
SimpliftDemandedBits, but that's going to require another code review
so reverting in the meantime.
llvm-svn: 237528
|
| |
|
|
| |
llvm-svn: 237526
|
| |
|
|
|
|
|
| |
This was the source of many leaks in the past, this should fix them once and
for all.
llvm-svn: 237524
|
| |
|
|
|
|
|
| |
DenseMap has great support for catching invalidated iterators now so we can get
rid of this crude hack. Use after frees are covered by asan.
llvm-svn: 237523
|
| |
|
|
|
|
| |
This is more than sufficient for all MC types.
llvm-svn: 237522
|
| |
|
|
|
|
|
| |
... I'd copied the check-next lines from a previous test so they were
slightly wrong, and had managed to test the wrong source tree. D'oh!
llvm-svn: 237521
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test timeouts were due to instcombine fighting itself. Regression test added.
Original log message:
Canonicalize min/max expressions correctly.
This patch introduces a canonical form for min/max idioms where one operand
is extended or truncated. This often happens when the other operand is a
constant. For example:
%1 = icmp slt i32 %a, i32 0
%2 = sext i32 %a to i64
%3 = select i1 %1, i64 %2, i64 0
Would now be canonicalized into:
%1 = icmp slt i32 %a, i32 0
%2 = select i1 %1, i32 %a, i32 0
%3 = sext i32 %2 to i64
This builds upon a patch posted by David Majenemer
(https://www.marc.info/?l=llvm-commits&m=143008038714141&w=2). That pass
passively stopped instcombine from ruining canonical patterns. This
patch additionally actively makes instcombine canonicalize too.
Canonicalization of expressions involving a change in type from int->fp
or fp->int are not yet implemented.
llvm-svn: 237520
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
But still handle them the same way since I don't know how they differ on
this target.
Of these, 'o' and 'v' are not tested but were already implemented.
I'm not sure why 'i' is required for X86 since it's supposed to be an
immediate constraint rather than a memory constraint. A test asserts
without it so I've included it for now.
No functional change intended.
Reviewers: nadav
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8254
llvm-svn: 237517
|
| |
|
|
|
|
|
|
|
|
|
| |
When the commit is not in the tree at all, find-rev returns 0
and prints an empty string. We need to catch that problem too,
when trying to revert.
Adding a list of possible problems, so that you can easily and
quickly correct without having to edit the script again.
llvm-svn: 237516
|
| |
|
|
|
|
| |
These were the old names for these operations long ago. NFC
llvm-svn: 237514
|
| |
|
|
|
|
| |
some unnecessary curly braces from the same area.
llvm-svn: 237513
|
| |
|
|
| |
llvm-svn: 237512
|
| |
|
|
|
|
| |
portion of the body based on what will also be the terminating condition. NFC
llvm-svn: 237511
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently whenever we sink any instruction, we do clearKillFlags for
every use of every use operand for that instruction, apparently there
are a lot of duplication, therefore compile time penalties.
This patch collect all the interested registers first, do clearKillFlags
for it all together at once at the end, so we only need to do
clearKillFlags once for one register, duplication is avoided.
Patch by Lawrence Hu!
Differential Revision: http://reviews.llvm.org/D9719
llvm-svn: 237510
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's no point in copying around constants, so, when all else fails,
we can still transform memcpy of memset into two independent memsets.
To quote the example, we can turn:
memset(dst1, c, dst1_size);
memcpy(dst2, dst1, dst2_size);
into:
memset(dst1, c, dst1_size);
memset(dst2, c, dst2_size);
When dst2_size <= dst1_size.
Like r235232 for copy constructors, this can occur in move constructors.
Differential Revision: http://reviews.llvm.org/D9682
llvm-svn: 237506
|
| |
|
|
| |
llvm-svn: 237503
|
| |
|
|
|
|
| |
Switch from `MCSymbolData` to `MCSymbol`.
llvm-svn: 237502
|
| |
|
|
| |
llvm-svn: 237501
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for the following new instructions in the
Power ISA 2.07:
vpksdss
vpksdus
vpkudus
vpkudum
vupkhsw
vupklsw
These instructions are available through the vec_packs, vec_packsu,
vec_unpackh, and vec_unpackl built-in interfaces. These are
lane-sensitive instructions, so the built-ins have different
implementations for big- and little-endian, and the instructions must
be marked as killing the vector swap optimization for now.
The first three instructions perform saturating pack operations. The
fourth performs a modulo pack operation, which means it can be
represented with a vector shuffle, and conversely the appropriate
vector shuffles may cause this instruction to be generated. The other
instructions are only generated via built-in support for now.
Appropriate tests have been added.
There is a companion patch to clang for the rest of this support.
llvm-svn: 237499
|
| |
|
|
|
|
|
|
| |
Transition one API from `MCSymbolData` to `MCSymbol`. The function
needs both, and the backpointer from `MCSymbolData` to `MCSymbol` is
going away.
llvm-svn: 237498
|
| |
|
|
|
|
|
| |
Change `MCFragment::Atom` from an `MCSymbolData` to an `MCSymbol`,
moving in the direction of removing the back-pointer.
llvm-svn: 237497
|
| |
|
|
|
|
|
|
| |
Instead of storing a list of the `MCSymbolData` in use, store the
`MCSymbol`s. Churning in the direction of removing the back pointer
from `MCSymbolData`.
llvm-svn: 237496
|
| |
|
|
|
|
|
|
| |
This would trigger an assertion later.
Bug found with AFL fuzz.
llvm-svn: 237494
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turn `MCSymbolData` into a field inside of `MCSymbol`. Keep all the old
API alive for now, so that consumers can be updated in a later commit.
This means we still temporarily need the back pointer from
`MCSymbolData` to `MCSymbol`, but I'll remove it in a follow-up.
This optimizes for object emission over assembly emission. By removing
the `DenseMap` in `MCAssembler`, llc memory usage drops from around 1040
MB to 1001 MB (3.8%).
(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`;
see r236629 for details.)
llvm-svn: 237490
|
| |
|
|
|
|
| |
Prepare for always including symbol data in MCSymbol.
llvm-svn: 237489
|
| |
|
|
| |
llvm-svn: 237488
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of an intrusive double-linked linked list, use a
`std::vector<>`. This saves a pointer per symbol and simplifies
`MCSymbolData`. Otherwise, no functionality change here.
While I measured a memory drop from around 1047MB to 1040MB (0.6%) --
and this is a decent cleanup in its own right -- it's primarily a
preparation patch for merging `MCSymbol` and `MCSymbolData`. I'll post
an updated patch for that to the list in a moment.
(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`;
see r236629 for details.)
llvm-svn: 237487
|
| |
|
|
|
|
|
|
|
| |
Stop exposing the storage for `MCAssembler::Symbols`, and have
`MCAssembler` add symbols directly to its list instead of using a hook
in `MCSymbolData`. This opens up room for a follow-up commit to switch
from a linked list to a vector.
llvm-svn: 237486
|
| |
|
|
| |
llvm-svn: 237483
|
| |
|
|
| |
llvm-svn: 237481
|
| |
|
|
|
|
|
|
|
|
| |
trimmed. NFC.
MCInstrDesc.h includes things like MCInst.h which i can now remove after this. That will be a future commit.
Reviewed by Jim Grosbach.
llvm-svn: 237478
|
| |
|
|
|
|
|
|
|
|
| |
isInt is a little easier to read, let's use that more consistently.
Incidentally, this also silences a warning for shifting a negative
number.
This fixes PR23532.
llvm-svn: 237476
|
| |
|
|
|
|
|
|
|
| |
Other pieces of CodeGen want to negate frame object offsets to account
for architectures where the stack grows down. Our object is a pseudo
object so it's offset doesn't matter. However, we shouldn't choose an
offset which results in undefined behavior if you negate it.
llvm-svn: 237474
|
| |
|
|
|
|
| |
s/InitMCCodeGenInfo/initMCCodeGenInfo/
llvm-svn: 237471
|
| |
|
|
| |
llvm-svn: 237470
|
| |
|
|
|
|
| |
s/EncodeInstruction/encodeInstruction/
llvm-svn: 237469
|
| |
|
|
|
|
| |
s/MCFixup::Create/MCFixup::create/
llvm-svn: 237468
|
| |
|
|
| |
llvm-svn: 237462
|