When emitting the difference between two symbols, the standard behavior is
that the difference will be resolved to an absolute value if both of the
symbols are offsets from the same data fragment. This is undesirable on
architectures such as RISC-V where relaxation in the linker may cause the
computed difference to become invalid. This caused an issue when compiling to
object code, where the size of a function in the debug information was already
calculated even though it could change as a consequence of relaxation in the
subsequent linking stage.
This patch inhibits the resolution of symbol differences to absolute values
where the target's AsmBackend has declared that it does not want these to be
folded.
Differential Revision: https://reviews.llvm.org/D45773
Patch by Edward Jones.
llvm-svn: 339864
The windows SDK defines WORD_MAX, so any poor soul that wants to use LLVM in a project that depends on the windows SDK gets a build error.
Given that it actually describes the maximal value of WordType, it actually fits even better than WORD_MAX
Patch by: @miscco
Differential Revision: https://reviews.llvm.org/D50777
llvm-svn: 339863
The TagDecl *OwnedTagDecl in ElaboratedType is quite commonly
null (at least when parsing all of Boost, it is non-null for only about 600
of the 66k ElaboratedType). Therefore we can save a pointer in the
common case by storing it as a trailing object, and storing a bit in the
bit-fields of Type indicating when the pointer is null.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D50715
llvm-svn: 339862
The bit-fields of Type have enough space for the member
unsigned NumArgs of SubstTemplateTypeParmPackType.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D50713
llvm-svn: 339861
The bit-fields of `Type` have enough space for the member
`unsigned NumArgs` of `DependentTemplateSpecializationType`.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D50712
llvm-svn: 339860
Originally committed in r339755 which was reverted in r339806 due to
an asan issue. The issue was caused by my assumption that operands to
a CallInst mapped to the FunctionType Params. CallInsts are now
handled by iterating over their ArgOperands instead of Operands.
Original Message:
Treat signed icmps as 'sinks', allowing them to be in the use-def
tree, enabling more promotions to be performed. As a sink, any
promoted incoming values need to be truncated before being used by
the signed icmp.
Differential Revision: https://reviews.llvm.org/D50067
llvm-svn: 339858
Mipsr6 does not possess HI and LO accumulator registers, adjust validRegister functions to respect that.
Differential Revision: https://reviews.llvm.org/D50244
llvm-svn: 339849
The __mips_fpr macro can take the value of 0 as well, change to account for that case.
Differential Revision: https://reviews.llvm.org/D50245
llvm-svn: 339848
a shorter name ('x86-slh') for the internal flags and pass name.
Without this, you can't use the -stop-after or -stop-before
infrastructure. I seem to have just missed this when originally adding
the pass.
The shorter name solves two problems. First, the flag names were ...
really long and hard to type/manage. Second, the pass name can't be the
exact same as the flag name used to enable this, and there are already
some users of that flag name so I'm avoiding changing it unnecessarily.
llvm-svn: 339836
Summary:
Profile count of a block is computed by multiplying its block frequency
by entry count and dividing the result by entry block frequency. Do
rounded division in the last step and update test cases appropriately.
Reviewers: davidxl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50822
llvm-svn: 339835
when we have only an in-memory copy of the binary.
Also added a test for the generation of these symbols in the
in-memory and regular cases.
<rdar://problem/43160401>
llvm-svn: 339833
Summary: Extended `cxx_loop_proto` to have neste for loops. Modified `loop_proto_to_llvm` and `loop_proto_to_cxx` to handle the new protos. All protos have a set of statements designated as "inner loop" statements and a set of statements designated as "outer loop" statements.
Reviewers: morehouse, kcc
Reviewed By: morehouse
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D50670
llvm-svn: 339832
In r339807, I broke linking the builtins libraries for simulator targets, which itself was bad, but turns out it was all completely untested and marked with FIXME in the test suite.
This fixes all the test cases so they actually work, and fixes the bug I introduced in r339807.
llvm-svn: 339829
Patch by Shafik Yaghmour!
This reapplies an earlier version after addressing some post-commit feedback.
Differential Revision: https://reviews.llvm.org/D49271
llvm-svn: 339828
This patch fixes PR38125.
Instruction extension types are recorded in PromotedInsts, it can be used later in function canGetThrough. If an instruction has two users with different extension types, it will be inserted into PromotedInsts two times in function promoteOperandForOther. The second one overwrites the first one, and the final extension type is wrong, later causes problem in canGetThrough.
This patch changes the simple bool extension type to 2-bit enum type, add a BothExtension type in addition to zero/sign extension. When an user sees BothExtension for an instruction, it actually knows nothing about how that instruction is extended.
Differential Revision: https://reviews.llvm.org/D49512
llvm-svn: 339822
Handle fmul, fsub and preserve flags.
Also really test minnum/maxnum reductions.
The existing tests were only checking from
minnum/maxnum matched from a fast math compare
and select which is not the same.
llvm-svn: 339820
To lower this we now create a new V1 containing the low half of both sources and a new V2 containing the upper half of both sources. Then we created a repeated lane shuffle of those new sources to create the final result.
This fixes PR35833
Differential Revison: https://reviews.llvm.org/D41794
llvm-svn: 339818
I noticed this during profiling of tablegen (PR28222) that we were calling Child->getType(0) which creates a ValueTypeByHwMode on the fly from the requested internal TypeSetByHwMode type and returns it by value, we then treat it as a TypeSetByHwMode reference which involves constructing a new TypeSetByHwMode on the stack with a large amount of std::map iterating/copying all along the way.
I am not an expert on tablegen, but AFAICT this is all unnecessary and we should be calling Child->getExtType(0) which returns the original TypeSetByHwMode by reference.
This gives me a 90sec reduction in msvc debug builds of x86 -gen-dag-isel.
Differential Revision: https://reviews.llvm.org/D50789
llvm-svn: 339812
Summary:
Migrate callers to print().
dump() should be useful to downstreams and third parties as a debugging
aid. Everyone trips up on this and creates confusing output.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50661
llvm-svn: 339810
MCJIT::getSymbolAddress was handling a non-fatal error condition of JITSymbol
as fatal. JITSymbol::operator bool returns false if no address is available
but no error is set. This can occur e.g. if the symbol name was not found.
Patch by Jascha Wetzel. Thanks Jascha!
llvm-svn: 339809
George Rimar