| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
compare to general register, and inverted compares.
llvm-svn: 224989
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 224986
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In an assembly expression like
bar:
.long L0 + 1
the intended semantics is that bar will contain a pointer one byte past L0.
In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.
The solution used in ELF to use relocation with symbols if there is a non-zero
addend.
In MachO before this patch we would just keep all symbols in some sections.
This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.
This patch implements the non-zero addend logic for MachO too.
llvm-svn: 224985
|
|
|
|
|
|
|
|
|
|
| |
Nothing particularly interesting, just adding infrastructure for use by in tree users and out of tree users.
Note: These were extracted out of a working frontend, but they have not been well tested in isolation.
Differential Revision: http://reviews.llvm.org/D6807
llvm-svn: 224981
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change implements four basic optimizations:
If a relocated value isn't used, it doesn't need to be relocated.
If the value being relocated is null, relocation doesn't change that. (Technically, this might be collector specific. I don't know of one which it doesn't work for though.)
If the value being relocated is undef, the relocation is meaningless.
If the value being relocated was known nonnull, the relocated pointer also isn't null. (Since it points to the same source language object.)
I outlined other planned work in comments.
Differential Revision: http://reviews.llvm.org/D6600
llvm-svn: 224968
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In LICM, we have a check for an instruction which is guaranteed to execute and thus can't introduce any new faults if moved to the preheader. To handle a function which might unconditionally throw when first called, we check for any potentially throwing call in the loop and give up.
This is unfortunate when the potentially throwing condition is down a rare path. It prevents essentially all LICM of potentially faulting instructions where the faulting condition is checked outside the loop. It also greatly diminishes the utility of loop unswitching since control dependent instructions - which are now likely in the loops header block - will not be lifted by subsequent LICM runs.
define void @nothrow_header(i64 %x, i64 %y, i1 %cond) {
; CHECK-LABEL: nothrow_header
; CHECK-LABEL: entry
; CHECK: %div = udiv i64 %x, %y
; CHECK-LABEL: loop
; CHECK: call void @use(i64 %div)
entry:
br label %loop
loop: ; preds = %entry, %for.inc
%div = udiv i64 %x, %y
br i1 %cond, label %loop-if, label %exit
loop-if:
call void @use(i64 %div)
br label %loop
exit:
ret void
}
The current patch really only helps with non-memory instructions (i.e. divs, etc..) since the maythrow call down the rare path will be considered to alias an otherwise hoistable load. The one exception is that it does kick in for loads which are known to be invariant without regard to other possible stores, i.e. those marked with either !invarant.load metadata of tbaa 'is constant memory' metadata.
Differential Revision: http://reviews.llvm.org/D6725
llvm-svn: 224965
|
|
|
|
|
|
|
|
|
|
| |
This patches fixes a miscompile where we were assuming that loading from null is undefined and thus we could assume it doesn't happen. This transform is perfectly legal in address space 0, but is not neccessarily legal in other address spaces.
We really should introduce a hook to control this property on a per target per address space basis. We may be loosing valuable optimizations in some address spaces by being too conservative.
Original patch by Thomas P Raoux (submitted to llvm-commits), tests and formatting fixes by me.
llvm-svn: 224961
|
|
|
|
|
|
| |
post-increment circular register stores, and bit reversed post-increment stores.
llvm-svn: 224957
|
|
|
|
| |
llvm-svn: 224955
|
|
|
|
| |
llvm-svn: 224953
|
|
|
|
|
|
| |
form stores with tests.
llvm-svn: 224952
|
|
|
|
|
|
| |
have encoding bits.
llvm-svn: 224951
|
|
|
|
|
|
| |
classes and instruction defs.
llvm-svn: 224949
|
|
|
|
|
|
| |
convertible to three address instructions, but aren't really.
llvm-svn: 224940
|
|
|
|
|
|
| |
functionality to the 0x80 opcode instructions, but are not valid in 64-bit mode.
llvm-svn: 224939
|
|
|
|
|
|
| |
for another change. NFC.
llvm-svn: 224938
|
|
|
|
| |
llvm-svn: 224937
|
|
|
|
|
|
| |
Patch by Michael Neumann.
llvm-svn: 224936
|
|
|
|
|
|
| |
No intended functionality change.
llvm-svn: 224935
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The else case ResultReg was not checked for validity.
To my surprise, this case was not hit in any of the
existing test cases. This includes a new test cases
that tests this path.
Also drop the `target triple` declaration from the
original test as suggested by H.J. Lu, because
apparently with it the test won't be run on Linux
llvm-svn: 224901
|
|
|
|
|
|
|
|
| |
Adds missing memory instruction variants to AVX false dependency breaking handling. (SSE was handled in r224246)
Differential Revision: http://reviews.llvm.org/D6780
llvm-svn: 224900
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
@llvm.cttz/ctlz.
If the control flow is modelling an if-statement where the only instruction in
the 'then' basic block (excluding the terminator) is a call to cttz/ctlz,
CodeGenPrepare can try to speculate the cttz/ctlz call and simplify the control
flow graph.
Example:
\code
entry:
%cmp = icmp eq i64 %val, 0
br i1 %cmp, label %end.bb, label %then.bb
then.bb:
%c = tail call i64 @llvm.cttz.i64(i64 %val, i1 true)
br label %end.bb
end.bb:
%cond = phi i64 [ %c, %then.bb ], [ 64, %entry]
\code
In this example, basic block %then.bb is taken if value %val is not zero.
Also, the phi node in %end.bb would propagate the size-of in bits of %val
only if %val is equal to zero.
With this patch, CodeGenPrepare will try to hoist the call to cttz from %then.bb
into basic block %entry only if cttz is cheap to speculate for the target.
Added two new hooks in TargetLowering.h to let targets customize the behavior
(i.e. decide whether it is cheap or not to speculate calls to cttz/ctlz). The
two new methods are 'isCheapToSpeculateCtlz' and 'isCheapToSpeculateCttz'.
By default, both methods return 'false'.
On X86, method 'isCheapToSpeculateCtlz' returns true only if the target has
LZCNT. Method 'isCheapToSpeculateCttz' only returns true if the target has BMI.
Differential Revision: http://reviews.llvm.org/D6728
llvm-svn: 224899
|
|
|
|
|
|
|
|
| |
Masked vector intrinsics are a part of common LLVM IR, but they are really supported on AVX2 and AVX-512 targets. I added a code that translates masked intrinsic for all other targets. The masked vector intrinsic is converted to a chain of scalar operations inside conditional basic blocks.
http://reviews.llvm.org/D6436
llvm-svn: 224897
|
|
|
|
|
|
| |
with illegal immediates. Correctly this time. I did the wrong patterns the first time.
llvm-svn: 224891
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Determining the address of a TLS variable results in a function call in
certain TLS models. This means that a simple ICmpInst might actually
result in invalidating the CTR register.
In such cases, do not attempt to rely on the CTR register for loop
optimization purposes.
This fixes PR22034.
Differential Revision: http://reviews.llvm.org/D6786
llvm-svn: 224890
|
|
|
|
|
|
| |
without asserts. NFC.
llvm-svn: 224889
|
|
|
|
|
|
| |
-Wunused-but-set-variable warning; NFC.
llvm-svn: 224888
|
|
|
|
|
|
| |
with illegal immediates. Forgot to do this when I did SSE/SSE2/AVX/AVX2.
llvm-svn: 224887
|
|
|
|
|
|
| |
cmp.ps/pd/ss/sd instead of truncating the immediate. The assembly parser and instruction selection shouldn't generate invalid immediates.
llvm-svn: 224886
|
|
|
|
|
|
| |
immediates. The frontend now checks this when the builtin is used. This will allow the instruction printer to not have to deal with invalid immediates on these instructions.
llvm-svn: 224885
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Consider the following IR:
%3 = load i8* undef
%4 = trunc i8 %3 to i1
%5 = call %jl_value_t.0* @foo(..., i1 %4, ...)
ret %jl_value_t.0* %5
Bools (that are the result of direct truncs) are lowered as whatever
the argument to the trunc was and a "and 1", causing the part of the
MBB responsible for this argument to look something like this:
%vreg8<def,tied1> = AND8ri %vreg7<kill,tied0>, 1, %EFLAGS<imp-def>; GR8:%vreg8,%vreg7
Later, when the load is lowered, it will insert
%vreg15<def> = MOV8rm %vreg14, 1, %noreg, 0, %noreg; mem:LD1[undef] GR8:%vreg15 GR64:%vreg14
but remember to (at the end of isel) replace vreg7 by vreg15. Now for
the bug. In fast isel lowering, we mistakenly mark vreg8 as the result
of the load instead of the trunc. This adds a fixup to have
vreg8 replaced by whatever the result of the load is as well, so
we end up with
%vreg15<def,tied1> = AND8ri %vreg15<kill,tied0>, 1, %EFLAGS<imp-def>; GR8:%vreg15
which is an SSA violation and causes problems later down the road.
This fixes PR21557.
Test Plan: Test test case from PR21557 is added to the test suite.
Reviewers: ributzka
Reviewed By: ributzka
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6245
llvm-svn: 224884
|
|
|
|
| |
llvm-svn: 224871
|
|
|
|
| |
llvm-svn: 224870
|
|
|
|
| |
llvm-svn: 224869
|
|
|
|
|
|
| |
unused classes.
llvm-svn: 224868
|
|
|
|
| |
llvm-svn: 224867
|
|
|
|
| |
llvm-svn: 224866
|
|
|
|
|
|
| |
references to them.
llvm-svn: 224862
|
|
|
|
|
|
| |
Similar fix to not fail to disassembler CR9-CR15 references.
llvm-svn: 224861
|
|
|
|
|
|
| |
enabled on Windows
llvm-svn: 224860
|
|
|
|
|
|
|
| |
A multiply cannot unsigned wrap if there are bitwidth, or more, leading
zero bits between the two operands.
llvm-svn: 224849
|
|
|
|
|
|
|
| |
Constant contains the isAllOnesValue and isNullValue predicates, not
ConstantInt.
llvm-svn: 224848
|
|
|
|
|
|
|
| |
We already utilize this logic for reducing overflow intrinsics, it makes
sense to reuse it for normal multiplies as well.
llvm-svn: 224847
|
|
|
|
|
|
| |
instructions. Instead of rejecting we'll just generate the _alt forms that don't try to alter the mnemonic. While I'm here, merge some common code in the Instruction printers for the condition code replacement and fix the mask on SSE to be 3-bits instead of 4.
llvm-svn: 224846
|
|
|
|
| |
llvm-svn: 224845
|
|
|
|
|
|
|
|
|
|
|
| |
When materializing constant i1 values, they must be zero extended. We represent
i1 values as [0, 1], not [0, -1], in i32 registers. As it turns out, this code
path was dead for i1 values prior to r216006 (which is why this did not manifest in
miscompiles until recently).
Fixes -O0 self-hosting on PPC64/Linux.
llvm-svn: 224842
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 224833
|
|
|
|
|
|
|
| |
No functional changes.
The documentation is coming.
llvm-svn: 224829
|
|
|
|
|
|
|
| |
It's possible to have a prior definition of a symbol in module asm.
Raise an error instead of crashing.
llvm-svn: 224828
|
|
|
|
| |
llvm-svn: 224827
|