| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug where one can take the address of a conditionally
enabled function to drop its enable_if guards. For example:
int foo(int a) __attribute__((enable_if(a > 0, "")));
int (*p)(int) = &foo;
int result = p(-1); // compilation succeeds; calls foo(-1)
Overloading logic has been updated to reflect this change, as well.
Functions with enable_if attributes that are always true are still
allowed to have their address taken.
Differential Revision: http://reviews.llvm.org/D13607
llvm-svn: 250090
|
| |
|
|
|
|
|
|
| |
In JumpThreading pass, the branch weight metadata is not updated after CFG modification. Consider the jump threading on PredBB, BB, and SuccBB. After jump threading, the weight on BB->SuccBB should be adjusted as some of it is contributed by the edge PredBB->BB, which doesn't exist anymore. This patch tries to update the edge weight in metadata on BB->SuccBB by scaling it by 1 - Freq(PredBB->BB) / Freq(BB->SuccBB).
Differential revision: http://reviews.llvm.org/D10979
llvm-svn: 250089
|
| |
|
|
|
|
|
|
|
| |
We made them SP relative back in March (r233137) because that's the
value the runtime passes to EH functions. With the new cleanuppad IR,
funclets adjust their frame argument from SP to FP, so our offsets
should now be FP-relative.
llvm-svn: 250088
|
| |
|
|
|
|
|
| |
Rafael requested some additional commentary (post-commit review of r249760), to
make it clear this is intended and necessary.
llvm-svn: 250087
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D13518
llvm-svn: 250086
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Function LowerVSETCC (in X86ISelLowering.cpp) worked under the wrong
assumption that for non-AVX512 targets, the source type and destination type
of a type-legalized setcc node were always the same type.
This assumption was unfortunately incorrect; the type legalizer is not always
able to promote the return type of a setcc to the same type as the first
operand of a setcc.
In the case of a vsetcc node, the legalizer firstly checks if the first input
operand has a legal type. If so, then it promotes the return type of the vsetcc
to that same type. Otherwise, the return type is promoted to the 'next legal
type', which, for vectors of MVT::i1 is always a 128-bit integer vector type.
Example (-mattr=+avx):
%0 = trunc <8 x i32> %a to <8 x i23>
%1 = icmp eq <8 x i23> %0, zeroinitializer
The initial selection dag for the code above is:
v8i1 = setcc t5, t7, seteq:ch
t5: v8i23 = truncate t2
t2: v8i32,ch = CopyFromReg t0, Register:v8i32 %vreg1
t7: v8i32 = build_vector of all zeroes.
The type legalizer would firstly check if 't5' has a legal type. If so, then it
would reuse that same type to promote the return type of the setcc node.
Unfortunately 't5' is of illegal type v8i23, and therefore it cannot be used to
promote the return type of the setcc node. Consequently, the setcc return type
is promoted to v8i16. Later on, 't5' is promoted to v8i32 thus leading to the
following dag node:
v8i16 = setcc t32, t25, seteq:ch
where t32 and t25 are now values of type v8i32.
Before this patch, function LowerVSETCC would have wrongly expanded the setcc
to a single X86ISD::PCMPEQ. Surprisingly, ISel was still able to match an
instruction. In our case, ISel would have matched a VPCMPEQWrr:
t37: v8i16 = X86ISD::VPCMPEQWrr t36, t25
However, t36 and t25 are both VR256, while the result type is instead of class
VR128. This inconsistency ended up causing the insertion of COPY instructions
like this:
%vreg7<def> = COPY %vreg3; VR128:%vreg7 VR256:%vreg3
Which is an invalid full copy (not a sub register copy).
Eventually, the backend would have hit an UNREACHABLE "Cannot emit physreg copy
instruction" in the attempt to expand the malformed pseudo COPY instructions.
This patch fixes the problem adding the missing logic in LowerVSETCC to handle
the corner case of a setcc with 128-bit return type and 256-bit operand type.
This problem was originally reported by Dimitry as PR25080. It has been latent
for a very long time. I have added the minimal reproducible from that bugzilla
as test setcc-lowering.ll.
Differential Revision: http://reviews.llvm.org/D13660
llvm-svn: 250085
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
InferiorCallPOSIX. It was
set to true, but all plans run by RunThreadPlan need to have this set to false so they will
return control to RunThreadPlan without consulting plans higher on the stack.
Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior.
<rdar://problem/22543166>
llvm-svn: 250084
|
| |
|
|
|
|
|
| |
strictly necessary because RunToAddress is always used as a subsidiary plan, so
it's ShouldStop seldom matters. But get it right anyway.
llvm-svn: 250083
|
| |
|
|
| |
llvm-svn: 250082
|
| |
|
|
| |
llvm-svn: 250081
|
| |
|
|
| |
llvm-svn: 250080
|
| |
|
|
| |
llvm-svn: 250079
|
| |
|
|
|
|
|
|
|
| |
Fixed a bug where we'd emit multiple diagnostics if there was a problem
taking the address of an overloaded template function.
Differential Revision: http://reviews.llvm.org/D13664
llvm-svn: 250078
|
| |
|
|
| |
llvm-svn: 250077
|
| |
|
|
| |
llvm-svn: 250076
|
| |
|
|
| |
llvm-svn: 250075
|
| |
|
|
|
|
| |
class. Also fix a naming issue. NFC.
llvm-svn: 250074
|
| |
|
|
| |
llvm-svn: 250073
|
| |
|
|
| |
llvm-svn: 250072
|
| |
|
|
| |
llvm-svn: 250071
|
| |
|
|
|
|
|
| |
No tests fail with this enabled so I assume it was an accident
that it isn't enabled now.
llvm-svn: 250070
|
| |
|
|
| |
llvm-svn: 250069
|
| |
|
|
|
|
|
|
| |
This was a minor bug in r249492. Calling PrepareEHLandingPad on a
non-landingpad was a no-op, but it attempted to get the generic pointer
register class, which apparently doesn't exist for some targets.
llvm-svn: 250068
|
| |
|
|
|
|
| |
Differential Revision http://reviews.llvm.org/D13518
llvm-svn: 250067
|
| |
|
|
|
|
|
|
| |
Patch by Alexey Bataev
Differential Revision: http://reviews.llvm.org/D13661
llvm-svn: 250066
|
| |
|
|
|
|
|
| |
CatchObjRecoverIdx was used for the old scheme, it is no longer
relevant.
llvm-svn: 250065
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Many small improvements to LLVM_BUILD_EXTERNAL_COMPILER_RT.
* Works correctly with Ninja by working around CMake Bug 14771 (https://cmake.org/Bug/view.php?id=14771)
* Has install-compiler-rt target, and installs as part of the default install target
* Sets the install paths properly so that it matches the non-standalone build
* Only generate the test targets if(LLVM_INCLUDE_TESTS)
Reviewers: samsonov, Bigcheese
Differential Revision: http://reviews.llvm.org/D13399
llvm-svn: 250064
|
| |
|
|
| |
llvm-svn: 250063
|
| |
|
|
|
|
|
|
| |
In order to actually verify the condition, we have to use a weak symbol.
If an undefined symbol is not used at all, it is naturally ignored not by
the code for --as-needed but by the code for something else.
llvm-svn: 250062
|
| |
|
|
| |
llvm-svn: 250061
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a more principled version of what I did earlier. Path
normalization is generally a good thing, but may break users in strange
environments, e. g. using lots of symlinks. Let the user choose and
default it to on.
This also changes adding a duplicated file into returning an error if
the file contents are different instead of an assertion failure.
Differential Revision: http://reviews.llvm.org/D13658
llvm-svn: 250060
|
| |
|
|
| |
llvm-svn: 250059
|
| |
|
|
|
|
|
|
| |
addu.qb implementation
Differential Revision: http://reviews.llvm.org/D12798
llvm-svn: 250058
|
| |
|
|
| |
llvm-svn: 250057
|
| |
|
|
|
|
|
|
|
|
| |
On targets where f32 is not legal, we have to look through a BITCAST SDNode to
find the register that an argument is stored in when emitting debug info, or we
will not be able to emit a DW_AT_location for it.
Differential Revision: http://reviews.llvm.org/D13005
llvm-svn: 250056
|
| |
|
|
| |
llvm-svn: 250055
|
| |
|
|
| |
llvm-svn: 250054
|
| |
|
|
| |
llvm-svn: 250053
|
| |
|
|
|
|
|
| |
Functions in this test case need to be renamed as its names are the same
as the instructions we are comparing with.
llvm-svn: 250052
|
| |
|
|
| |
llvm-svn: 250051
|
| |
|
|
| |
llvm-svn: 250050
|
| |
|
|
| |
llvm-svn: 250049
|
| |
|
|
| |
llvm-svn: 250048
|
| |
|
|
| |
llvm-svn: 250047
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, fs::rename() could fail is another process was reading the
file at the same time using fs::openFileForRead(). In most cases the user
wouldn't notice as fs::rename() will continue to retry for 2000ms. Typically
this is enough for the read to complete and a retry to succeed, but if the
disk is being it too hard then the response time might be longer than the
retry time and the rename would fail with a permission error.
Add FILE_SHARE_DELETE to the sharing flags for CreateFileW() in
fs::openFileForRead() and try ReplaceFileW() prior to MoveFileExW()
in fs::rename().
Based on an initial patch by Edd Dawson!
Differential Revision: http://reviews.llvm.org/D13647
llvm-svn: 250046
|
| |
|
|
| |
llvm-svn: 250045
|
| |
|
|
|
|
|
|
| |
This prevents a "too many files" error.
Differential Revision: http://reviews.llvm.org/D13555
llvm-svn: 250044
|
| |
|
|
| |
llvm-svn: 250043
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
register belongs.
Summary: Fixes PR24915.
Reviewers: vkalintiris
Subscribers: emaste, seanbruno, llvm-commits
Differential Revision: http://reviews.llvm.org/D13533
llvm-svn: 250042
|
| |
|
|
|
|
|
|
| |
changes. NFC.
Mostly tabs -> spaces and double spacing.
llvm-svn: 250041
|