| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
Fixes verifier errors with Windows EH and OpenMP, which injects a
terminate scope around parallel blocks.
Fixes PR35778
llvm-svn: 321676
|
|
|
|
|
|
|
|
| |
This patch enables OMPT by default if version 50 or later is built and the config says, that OMPT will be supported.
Differential Revision: https://reviews.llvm.org/D41508
llvm-svn: 321675
|
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D40524
Change-Id: Ie3a405b28503ceae999f5f3ba07a68fa733a2400
llvm-svn: 321674
|
|
|
|
| |
llvm-svn: 321673
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is part of solving PR35717:
https://bugs.llvm.org/show_bug.cgi?id=35717
The larger IR optimization is proposed in D41603, but we can show
the improvement in ValueTracking using codegen tests because
SelectionDAG creates min/max nodes based on ValueTracking.
Any target with min/max ops should show wins here. I chose AArch64
vector ops because they're clean and uniform.
Some Alive proofs for the tests (can't put more than 2 tests in 1
page currently because the web app says it's too long):
https://rise4fun.com/Alive/WRN
https://rise4fun.com/Alive/iPm
https://rise4fun.com/Alive/HmY
https://rise4fun.com/Alive/CNm
https://rise4fun.com/Alive/LYf
llvm-svn: 321672
|
|
|
|
|
|
|
|
|
|
|
| |
- Fix formatting issue due to hyphenated terms at line breaks.
- Fix typo
This patch was made by Craig Flores
Differential Revision: https://reviews.llvm.org/D41520
llvm-svn: 321671
|
|
|
|
|
|
|
|
|
|
| |
- Fix incorrect wording in various intrinsic descriptions. Previously the descriptions used "low-order" and "high-order" when the intended meaning was "even-indexed" and "odd-indexed".
This patch was made by Craig Flores
Differential Revision: https://reviews.llvm.org/D41518
llvm-svn: 321670
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Fixed innaccurate instruction mappings for various intrinsics.
- Fixed description of NaN handling in comparison intrinsics.
- Unify description of _mm_store_pd1 to match _mm_store1_pd.
- Fix incorrect wording in various intrinsic descriptions. Previously the descriptions used "low-order" and "high-order" when the intended meaning was "even-indexed" and "odd-indexed".
- Fix typos.
- Add missing italics command (\a) for params and fixed some parameter spellings.
This patch was made by Craig Flores
Differential Revision: https://reviews.llvm.org/D41516
llvm-svn: 321669
|
|
|
|
| |
llvm-svn: 321668
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Initial working version of libunwind for PowerPC 64. Tested on
little-endian ppc64 host only.
Based on the existing PowerPC 32 code.
It supports:
- context save/restore (unw_getcontext, unw_init_local, unw_resume)
- read/write from/to saved registers
- backtrace (unw_step)
Patch by Leandro Lupori!
Differential Revision: https://reviews.llvm.org/D41386
llvm-svn: 321667
|
|
|
|
| |
llvm-svn: 321666
|
|
|
|
|
|
|
|
| |
system header.
The way to fix an undefined-template warning is to add lines to the header file that defines the template pattern. We should suppress the warnings when the template pattern is in a system header because we don't expect users to edit those.
llvm-svn: 321665
|
|
|
|
| |
llvm-svn: 321664
|
|
|
|
|
|
| |
exported from the dylib.
llvm-svn: 321663
|
|
|
|
|
|
|
|
| |
A call may have an intrinsic name but not have a valid intrinsic ID,
for example with llvm.invariant.group.barrier. If so, treat it as a
normal call like FastISel does.
llvm-svn: 321662
|
|
|
|
| |
llvm-svn: 321661
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rdar://problem/33251668
Reviewers: arphaman, ahatanak
Reviewed By: arphaman
Subscribers: ptitei, cfe-commits
Differential Revision: https://reviews.llvm.org/D41528
llvm-svn: 321660
|
|
|
|
|
|
|
|
|
| |
Some systems still don't have this module which was introduced in
version 2.0 (CentOS 7, sigh).
Differential Revision: https://reviews.llvm.org/D41611
llvm-svn: 321659
|
|
|
|
|
|
| |
involved marking a lot of variables as inline (but only for C++17 and later).
llvm-svn: 321658
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We normally want to ignore SHT_NOBITS sections when computing
offsets. The sh_offset of section itself seems to be irrelevant and
- If the section is in the middle of a PT_LOAD, it will make no
difference on the computed offset of the followup section.
- If it is in the end of a PT_LOAD, we want to avoid its alignment
changing the offset of the followup sections.
The issue is if it is at the start of the PT_LOAD. In that case we do
have to align it so that the following sections have congruent address
and offset module the page size. We were not handling this case.
This should fix freebsd kernel link.
llvm-svn: 321657
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR33325)
This is an extension of D31156 with the goal that we'll allow memcmp() == 0 expansion
for x86 to use 2 pairs of loads per block.
The memcmp expansion pass (formerly part of CGP) will generate this kind of pattern
with oversized integer compares, so we want to transform these into x86-specific vector
nodes before legalization splits things into scalar chunks.
See PR33325 for more details:
https://bugs.llvm.org/show_bug.cgi?id=33325
Differential Revision: https://reviews.llvm.org/D41618
llvm-svn: 321656
|
|
|
|
|
|
|
|
|
|
|
| |
Tests updated to explicitly use fast-isel at -O0 instead of implicitly.
This change also allows an explicit -fast-isel option to override an
implicitly enabled global-isel. Otherwise -fast-isel would have no effect at -O0.
Differential Revision: https://reviews.llvm.org/D41362
llvm-svn: 321655
|
|
|
|
| |
llvm-svn: 321654
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
UpdateAnalysisInformation
Summary:
We are incorrectly updating the LI when loop-simplify generates
dedicated exit blocks for a loop. The issue is that there's an implicit
assumption that the Preds passed into UpdateAnalysisInformation are
reachable. However, this is not true and breaks LI by incorrectly
updating the header of a loop.
One such case is when we generate dedicated exits when the exit block is
a landing pad (through SplitLandingPadPredecessors). There maybe other
cases as well, since we do not guarantee that Preds passed in are
reachable basic blocks.
The added test case shows how loop-simplify breaks LI for the outer loop (and DT in turn)
after we try to generate the LoopSimplifyForm.
Reviewers: davide, chandlerc, sanjoy
Reviewed By: davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41519
llvm-svn: 321653
|
|
|
|
| |
llvm-svn: 321652
|
|
|
|
| |
llvm-svn: 321651
|
|
|
|
| |
llvm-svn: 321650
|
|
|
|
|
|
|
| |
Our internal testing has revealed has discovered bugs in PPC builds.
I have forward reproduction instructions to the original author (Nirav).
llvm-svn: 321649
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: ruiu, davidxl, silvas, brzycki
Reviewed By: brzycki
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41609
llvm-svn: 321648
|
|
|
|
|
|
|
|
| |
This reverts r321645.
I missed a compiler-rt test that needs updating.
llvm-svn: 321647
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
isReg() in AArch64AsmParser.cpp is a bit of a misnomer, and would be better named 'isScalarReg()' instead.
Patch [1/3] in a series to add operand constraint checks for SVE's predicated ADD/SUB.
Reviewers: rengolin, mcrosier, evandro, fhahn, echristo
Reviewed By: fhahn
Subscribers: aemerson, javed.absar, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D41445
llvm-svn: 321646
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The C++ Itanium ABI says:
No cookie is required if the new operator being used is ::operator new[](size_t, void*).
We should only avoid poisoning the cookie if we're calling this
operator, not others. This is dealt with before the call to
InitializeArrayCookie.
Reviewers: rjmccall, kcc, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41301
llvm-svn: 321645
|
|
|
|
| |
llvm-svn: 321644
|
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D41339
Patch by Shiva Chen.
llvm-svn: 321643
|
|
|
|
|
|
| |
XLenVT in LowerFormalArguments is used only in an assert.
llvm-svn: 321642
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the acceptance of ANY_EXTEND nodes while trying to move and
nodes back to loads.
Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=35765
Differential Revision: https://reviews.llvm.org/D41625
llvm-svn: 321641
|
|
|
|
|
|
| |
Committing reproducer test for pr35765, fix to follow.
llvm-svn: 321640
|
|
|
|
| |
llvm-svn: 321639
|
|
|
|
|
|
| |
result type would still be legal.
llvm-svn: 321638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch enables folding under -ffast-math flag sqrt(a) * sqrt(b) -> sqrt(a*b)
Reviewers: hfinkel, spatel, davide
Reviewed By: spatel, davide
Subscribers: davide, llvm-commits
Differential Revision: https://reviews.llvm.org/D41322
llvm-svn: 321637
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: Quolyk
Reviewed By: Quolyk
Differential Revision: https://reviews.llvm.org/D41561
llvm-svn: 321636
|
|
|
|
|
|
|
|
| |
of the WideVecOp handlers.
We should only be in the handler if the tyep action is TypeWidenVector. There's no reason to try to do anything else.
llvm-svn: 321635
|
|
|
|
|
|
| |
Reduced (as best I could...) from oss-fuzz #4857 test case
llvm-svn: 321634
|
|
|
|
| |
llvm-svn: 321633
|
|
|
|
| |
llvm-svn: 321632
|
|
|
|
|
|
| |
Currently we do a lot of scalarization in these test cases.
llvm-svn: 321631
|
|
|
|
|
|
| |
The custom lowering was just doing the same thing promotion would do.
llvm-svn: 321630
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when using setOperationAction Promote for INT_TO_FP and FP_TO_INT
Currently the promotion for these ignores the normal getTypeToPromoteTo and instead just tries to double the element width. This is because the default behavior of getTypeToPromote to just adds 1 to the SimpleVT, which has the affect of increasing the element count while keeping the scalar size the same.
If multiple steps are required to get to a legal operation type, int_to_fp will be promoted multiple times. And fp_to_int will keep trying wider types in a loop until it finds one that works.
getTypeToPromoteTo does have the ability to query a promotion map to get the type and not do the increasing behavior. It seems better to just let the target specify the promotion type in the map explicitly instead of letting the legalizer iterate via widening.
FWIW, it's worth I think for any other vector operations that need to be promoted, we have to specify the type explicitly because the default behavior of getTypeToPromote isn't useful for vectors. The other types of promotion already require either the element count is constant or the total vector width is constant, but neither happens by incrementing the SimpleVT enum.
Differential Revision: https://reviews.llvm.org/D40664
llvm-svn: 321629
|
|
|
|
|
|
|
|
|
|
|
|
| |
- reverts r321622, r321625, and r321626.
- the use of bit-fields is still resulting in warnings - even though we can use static-asserts to harden the code and ensure the bit-fields are wide enough. The bots still complain of warnings being seen.
- to silence the warnings requires specifying the bit-fields with the underlying enum type (as opposed to the enum type itself), which then requires lots of unnecessary static casts of each enumerator within DeclSpec to the underlying-type, which even though could be seen as implementation details, it does hamper readability - and given the additional litterings, makes me question the value of the change.
So in short - I give up (for now at least).
Sorry about the noise.
llvm-svn: 321628
|
|
|
|
|
|
|
|
| |
This should fix the test from https://reviews.llvm.org/D41128.
Differential Revision: https://reviews.llvm.org/D41649
llvm-svn: 321627
|