[PowerPC] Set PROT_READ flag for MF_EXEC to prevent segfaults on PPC machines
The big endian PPC buildbots are all failing now due to calls to cache
invalidation in unit tests on data that has only the PROT_EXEC flag set.
This has been an issue all along on FreeBSD but it can affect Linux machines
depending on configuration.
This patch mitigates the issue the same way it is mitigated on FreeBSD.
Since this is needed to bring the buildbots back to green, I plan to commit this
and allow for post-commit review, but I thought I would also post it here for
ease of access/readability.
Owen Reynolds [Mon, 3 Jun 2019 15:26:07 +0000 (15:26 +0000)]
[llvm-ar] Fix relative thin archive path handling
This fixes some thin archive relative path issues, paths are shortened where possible and paths are output correctly when using the display table command.
Michal Gorny [Mon, 3 Jun 2019 14:50:03 +0000 (14:50 +0000)]
[llvm] [test] Remove non-portable EISDIR test from macho-disassemble-g-dsym.test
Remove the test checking error message for 'is a directory'. It does
not seem to serve any real purpose, and it relies on matching platform
error strings which are unpredictable and makes the test fragile.
Furthermore, it fails on NetBSD where read() works on directories,
and therefore does not return EISDIR at all.
Dmitri Gribenko [Mon, 3 Jun 2019 12:42:48 +0000 (12:42 +0000)]
Include what you use in LanaiMCCodeEmitter.cpp
LanaiMCCodeEmitter.cpp was not using any APIs from Lanai.h, and was only
including it for transitive dependencies. Doing so is problematic from
include-what-you-use perspective, but it is also a layering issue (it
creates a dependency cycle between the primary Lanai target library and
the MCTargetDesc library).
Dmitri Gribenko [Mon, 3 Jun 2019 11:41:22 +0000 (11:41 +0000)]
Include what you use in HexagonInstPrinter.cpp
HexagonInstPrinter.cpp was not using any APIs from HexagonAsmPrinter.h.
Doing so is problematic from include-what-you-use perspective, but it is
also a layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).
Dmitri Gribenko [Mon, 3 Jun 2019 11:25:37 +0000 (11:25 +0000)]
Include what you use in HexagonMCInstrInfo.cpp
HexagonMCInstrInfo.cpp was not using any APIs from Hexagon.h. Doing so
is problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).
Dmitri Gribenko [Mon, 3 Jun 2019 11:20:53 +0000 (11:20 +0000)]
Include what you use in HexagonMCCodeEmitter.cpp
HexagonMCCodeEmitter.cpp was not using any APIs from Hexagon.h. Doing
so is problematic from include-what-you-use perspective, but it is also
a layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).
Dmitri Gribenko [Mon, 3 Jun 2019 11:20:48 +0000 (11:20 +0000)]
Include what you use in HexagonMCCompound.cpp
HexagonMCCompound.cpp was not using any APIs from Hexagon.h. Doing so
is problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).
Dmitri Gribenko [Mon, 3 Jun 2019 11:14:20 +0000 (11:14 +0000)]
Include what you use in HexagonShuffler.cpp
HexagonShuffler.cpp was not using any APIs from Hexagon.h, and was only
including it for transitive dependencies. Doing so is problematic from
include-what-you-use perspective, but it is also a layering issue (it
creates a dependency cycle between the primary Hexagon target library
and the MCTargetDesc library).
Dmitri Gribenko [Mon, 3 Jun 2019 11:14:15 +0000 (11:14 +0000)]
Include what you use in HexagonMCChecker.cpp
HexagonMCChecker.cpp was not using any APIs from Hexagon.h. Doing so is
problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).
Dmitri Gribenko [Mon, 3 Jun 2019 11:14:10 +0000 (11:14 +0000)]
Include what you use in HexagonMCTargetDesc.cpp
HexagonMCTargetDesc.cpp was not using any APIs from Hexagon.h. Doing so
is problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).
Dmitri Gribenko [Mon, 3 Jun 2019 11:14:05 +0000 (11:14 +0000)]
Include what you use in HexagonMCShuffler.cpp
HexagonMCShuffler.cpp was not using any APIs from Hexagon.h. Doing so
is problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).
Simon Tatham [Mon, 3 Jun 2019 11:02:53 +0000 (11:02 +0000)]
[ARM] Fix recent breakage of -mfpu=none.
The recent change D60691 introduced a bug in clang when handling
option combinations such as `-mcpu=cortex-m4 -mfpu=none`. Those
options together should select Cortex-M4 but disable all use of
hardware FP, but in fact, now hardware FP instructions can still be
generated in that mode.
The reason is because the handling of FPUVersion::NONE disables all
the same feature names it used to, of which the base one is `vfp2`.
But now there are further features below that, like `vfp2d16fp` and
(following D60694) `fpregs`, which also need to be turned off to
disable hardware FP completely.
Added a tiny test which double-checks that compiling a simple FP
function doesn't access the FP registers.
George Rimar [Mon, 3 Jun 2019 09:58:41 +0000 (09:58 +0000)]
[llvm-readobj] - Convert gnu-sections.test to use YAML.
gnu-sections.test currently use relocs.obj.elf-x86_64 and
relocs.obj.elf-i386 precompiled objects as an inputs.
These inputs actually initially were introduced to test the
dump of relocations and have almost nothing common with dumping
sections.
Patch converts the test to use yaml2obj. That allows to remove
relocs.obj.elf-i386 binary.
(relocs.obj.elf-x86_64 is still used by another test and can't be removed atm).
Dmitri Gribenko [Mon, 3 Jun 2019 09:56:40 +0000 (09:56 +0000)]
Include what you use in HexagonELFObjectWriter.cpp
HexagonELFObjectWriter.cpp was not using any APIs from Hexagon.h, and
was only including it for transitive dependencies. Doing so is
problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).
rL362089 introduced a set of yaml based reloc-types-*.test test cases
(instead of huge reloc-types.test that used a lot of precompiled binaries)
These test cases checks LLVM-styled dumping of the relocations.
gnu-relocations.test was a test case to check GNU styled relocations dumping.
It did that only for elf-x86 and elf-x86_64 targets. It did not test all of the
relocations though.
Now, after rL362089, it does not make sence to keep it.
This patch updates reloc-types-elf-i386.test and reloc-types-elf-x64.test tests
with llvm-readelf calls to check GNU styled output in one place.
It removes gnu-relocations.test completely.
One of intentions of doing this is also to get rid of relocs.obj.elf-i386 and
relocs.obj.elf-x86_64 precompiled objects completely (they are used in other tests still).
Nikola Prica [Mon, 3 Jun 2019 09:48:29 +0000 (09:48 +0000)]
[LiveDebugValues] Close range for previous variable's location when adding newly deduced location
When LiveDebugValues deduces new variable's location from spill, restore or
register copy instruction it should close old variable's location. Otherwise
we can have multiple block output locations for same variable. That could lead
to inserting two DBG_VALUEs for same variable to the beginning of the successor
block which results to ignoring of first DBG_VALUE.
Dmitri Gribenko [Mon, 3 Jun 2019 09:43:05 +0000 (09:43 +0000)]
Include what you use in HexagonAsmBackend.cpp
HexagonAsmBackend.cpp was not using any APIs from Hexagon.h. Doing so
is problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the MCTargetDesc library).
Dmitri Gribenko [Mon, 3 Jun 2019 09:38:48 +0000 (09:38 +0000)]
Include what you use in HexagonAsmParser.cpp
HexagonAsmParser.cpp was not using any APIs from Hexagon.h. Doing so is
problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
Hexagon target library and the AsmParser library).
Dmitri Gribenko [Mon, 3 Jun 2019 09:33:48 +0000 (09:33 +0000)]
Include what you use in HexagonShuffler.h
HexagonShuffler.h was not using any APIs from Hexagon.h, and was only
including it for transitive dependencies. Doing so is problematic from
include-what-you-use perspective, but it is also a layering issue (it
creates a dependency cycle between the primary Hexagon target library
and the MCTargetDesc library).
Dmitri Gribenko [Mon, 3 Jun 2019 09:29:51 +0000 (09:29 +0000)]
Include what you use in BPFMCTargetDesc.cpp
BPFMCTargetDesc.cpp was not using any APIs from BPF.h. Doing so is
problematic from include-what-you-use perspective, but it is also a
layering issue (it creates a dependency cycle between the primary
BPF target library and the MCTargetDesc library).
[ARM][FIX] Ran out of registers due tail recursion
Summary:
- pr42062
When compiling for MinSize,
ARMTargetLowering::LowerCall decides to indirect
multiple calls to a same function. However,
it disconsiders the limitation that thumb1
indirect calls require the callee to be in a
register from r0 to r3 (llvm limiation).
If all those registers are used by arguments, the
compiler dies with "error: run out of registers
during register allocation".
This patch tells the function
IsEligibleForTailCallOptimization if we intend to
perform indirect calls, as to avoid tail call
optimization.
Mikael Holmen [Mon, 3 Jun 2019 06:38:01 +0000 (06:38 +0000)]
[TableGen] Fix std::array initializer to avoid warnings with older tool chains. NFC
A std::array is implemented as a template with an array inside a struct.
Older versions of clang, like 3.6, require an extra set of curly braces
around std::array initializations to avoid warnings.
The C++ language was changed regarding this by CWG 1270. So more modern
tool chains does not complain even if leaving out one level of braces.
Jim Lin [Mon, 3 Jun 2019 02:31:07 +0000 (02:31 +0000)]
[AVR] Fix incorrect source regclass of LDWRdPtr
Summary:
LDWRdPtr would be expanded to ld+ldd. ldd only accepts the pointer register is Y or Z.
So the register class of pointer of LDWRdPtr should be PTRDISPREGS instead of PTRREGS.
Florian Hahn [Mon, 3 Jun 2019 01:30:19 +0000 (01:30 +0000)]
Recommit r360171: [DAGCombiner] Avoid creating large tokenfactors in visitTokenFactor.
If we hit the limit, we do expand the outstanding tokenfactors.
Otherwise, we might drop nodes with users in the unexpanded
tokenfactors. This fixes the crashes reported by Jordan Rupprecht.
Mike Spertus [Sun, 2 Jun 2019 23:33:32 +0000 (23:33 +0000)]
Update MSVC Visualizer to reflect new variadic PointerUnion
This changed updates the MSVC Visualizer to work with the recent change
of PointerUnion into a variadic template. As an extra bonus, we
fix some bit rot in the SmallPtrSet visualizer as well
Nico Weber [Sun, 2 Jun 2019 23:26:57 +0000 (23:26 +0000)]
llvm-undname; Add more test coverage for demangleFunctionClass()
Also add two FC_Far that seem to be missing, by symmetry from
the public and protected cases. (But FC_Far isn't really a thing
anymore, so this doesn't really have an observable effect.)
A mixture of internal tests and review of the scheduler models indicates we're overestimating the cost of a masked load, which we're estimating at 4x regular memory ops - more realistic values indicates that its closer to 2x. Masked stores costs are a lot more diverse but 8x is roughly in the middle of the range.
Don Hinton [Sun, 2 Jun 2019 15:53:43 +0000 (15:53 +0000)]
[test] Fix plugin tests
Recommit of r361790 that was temporarily reverted in r361793 due to bot breakage.
Summary:
The following changes were required to fix these tests:
1) Change LLVM_ENABLE_PLUGINS to an option and move it to
llvm/CMakeLists.txt with an appropriate default -- which matches
the original default behavior.
2) Move the plugins directory from clang/test/Analysis
clang/lib/Analysis. It's not enough to add an exclude to the
lit.local.cfg file because add_lit_testsuites recurses the tree and
automatically adds the appropriate `check-` targets, which don't
make sense for the plugins because they aren't tests and don't
have `RUN` statements.
Here's a list of the `clang-check-anlysis*` targets with this
change:
Simon Pilgrim [Sun, 2 Jun 2019 11:56:39 +0000 (11:56 +0000)]
[DAG] isBitwiseNot / isConstOrConstSplat - add support for build vector undefs + truncation (PR41020)
Add (opt-in) support for implicit truncation to isConstOrConstSplat, which allows us to match truncated 'all ones' cases in isBitwiseNot.
PR41020 compares against using ISD::isBuildVectorAllOnes() instead, but that predicate silently accepts any UNDEF elements in the build vector which might not be what we want in isBitwiseNot - so I've added an opt-in 'AllowUndefs' flag that is set to false by default but will allow us to enable it on individual cases where its safe.
Petr Hosek [Sun, 2 Jun 2019 02:05:01 +0000 (02:05 +0000)]
[CMake] Use libtool for runtimes when building for Apple platform
LLVM CMake build already uses libtool instead of ar when building
for Apple platform and we should be using the same when building
runtimes. To do so, this change extracts the logic for finding
libtool into a separate file and then uses it from both the LLVM
build as well as the LLVM runtimes build.
Craig Topper [Sun, 2 Jun 2019 01:36:48 +0000 (01:36 +0000)]
[X86] Fix several places that weren't passing what they though they were to MachineInstr::print
Over a year ago, MachineInstr gained a fourth boolean parameter that occurs
before the TII pointer. When this happened, several places started accidentally
passing TII into this boolean parameter instead of the TII parameter.
Extract a willNotOverflow() helper function that is shared between
eliminateOverflowIntrinsic() and strengthenOverflowingOperation().
Use WithOverflowInst for the former.
We'll be able to reuse the same code for saturating intrinsics as
well.
Craig Topper [Sat, 1 Jun 2019 19:40:07 +0000 (19:40 +0000)]
[InlineCost] Don't add the soft float function call cost for the fneg idiom, fsub -0.0, %x
Summary: Fneg can be implemented with an xor rather than a function call so we don't need to add the function call overhead. This was pointed out in D62699
Simon Atanasyan [Sat, 1 Jun 2019 13:55:18 +0000 (13:55 +0000)]
[mips] Extend range of register indexes accepted by cfcmsa/ctcmsa
The `cfcmsa` and `ctcmsa` instructions accept index of MSA control
register. The MIPS64 SIMD Architecture define eight MSA control
registers. But register index for `cfcmsa` and `ctcmsa` instructions
might be any number in 0..31 range. If the index is greater then 7,
`cfcmsa` writes zero to the destination registers and `ctcmsa` does
nothing [1].
[1] MIPS Architecture for Programmers Volume IV-j:
The MIPS64 SIMD Architecture Module
https://www.mips.com/?do-download=the-mips64-simd-architecture-module
Dylan McKay [Sat, 1 Jun 2019 12:38:56 +0000 (12:38 +0000)]
[AVR] Disable register coalescing to the PTRDISPREGS class
If we would allow register coalescing on PTRDISPREGS class then register
allocator can lock Z register to some virtual register. Larger instructions
requiring a memory acces then fail during the register allocation phase since
there is no available register to hold a pointer if Y register was already
taken for a stack frame. This patch prevents it by keeping Z register
spillable. It does it by not allowing coalescer to lock it.
Original discussion on https://github.com/avr-rust/rust/issues/128.
Roman Lebedev [Sat, 1 Jun 2019 11:08:29 +0000 (11:08 +0000)]
[NFC][Codegen] shift-amount-mod.ll: drop innermost operation
I have initially added it in for test to display both
whether the binop w/ constant is sinked or hoisted.
But as it can be seen from the 'sub (sub C, %x), %y'
test, that actually conceals the issues it is supposed to test.
At least two more patterns are unhandled:
* 'add (sub C, %x), %y' - D62266
* 'sub (sub C, %x), %y'
Nikita Popov [Sat, 1 Jun 2019 09:40:18 +0000 (09:40 +0000)]
[IndVarSimplify] Fixup nowrap flags during LFTR (PR31181)
Fix for https://bugs.llvm.org/show_bug.cgi?id=31181 and partial fix
for LFTR poison handling issues in general.
When LFTR moves a condition from pre-inc to post-inc, it may now
depend on value that is poison due to nowrap flags. To avoid this,
we clear any nowrap flag that SCEV cannot prove for the post-inc
addrec.
Additionally, LFTR may switch to a different IV that is dynamically
dead and as such may be arbitrarily poison. This patch will correct
nowrap flags in some but not all cases where this happens. This is
related to the adoption of IR nowrap flags for the pre-inc addrec.
(See some of the switch_to_different_iv tests, where flags are not
dropped or insufficiently dropped.)
Finally, there are likely similar issues with the handling of GEP
inbounds, but we don't have a test case for this yet.
Summary:
This was flagged in https://www.viva64.com/en/b/0629/ under "Snippet No.
33".
It seems that this statement is doing the standard bitwise trick for
adjusting a value to have a specific alignment.
The issue is that getStubAlignment() returns an unsigned, while DataSize
is declared a uint64_t. The right hand side of the expression is not
extended to 64b before bitwise negation, resulting in the top half of
the mask being 0s, which is not correct for realignment.
Tom Tan [Sat, 1 Jun 2019 02:38:08 +0000 (02:38 +0000)]
[COFF, ARM64] Fix location of ARM64 CodeView test
ARM64 CodeView test was incorrectly put under test/DebugInfo/COFF folder which
runs for all all architectures. This fix moves it to a subfolder AArch64 with
lit.local.cfg which specify it supports AArch64 only.
Philip Reames [Sat, 1 Jun 2019 00:31:58 +0000 (00:31 +0000)]
[LoopPred] Handle a subset of NE comparison based latches
At the moment, LoopPredication completely bails out if it sees a latch of the form:
%cmp = icmp ne %iv, %N
br i1 %cmp, label %loop, label %exit
OR
%cmp = icmp ne %iv.next, %NPlus1
br i1 %cmp, label %loop, label %exit
This is unfortunate since this is exactly the form that LFTR likes to produce. So, go ahead and recognize simple cases where we can.
For pre-increment loops, we leverage the fact that LFTR likes canonical counters (i.e. those starting at zero) and a (presumed) range fact on RHS to discharge the check trivially.
For post-increment forms, the key insight is in remembering that LFTR had to insert a (N+1) for the RHS. CVP can hopefully prove that add nsw/nuw (if there's appropriate range on N to start with). This leaves us both with the post-inc IV and the RHS involving an nsw/nuw add, and SCEV can discharge that with no problem.
This does still need to be extended to handle non-one steps, or other harder patterns of variable (but range restricted) starting values. That'll come later.
Eli Friedman [Sat, 1 Jun 2019 00:08:54 +0000 (00:08 +0000)]
[CodeGen] Fix hashing for MO_ExternalSymbol MachineOperands.
We were hashing the string pointer, not the string, so two instructions
could be identical (isIdenticalTo), but have different hash codes.
This showed up as a very rare, non-deterministic assertion failure
rehashing a DenseMap constructed by MachineOutliner. So there's no
"real" testcase, just a unittest which checks that the hash function
behaves correctly.
I'm a little scared fixing this is going to cause a regression in
outlining or MachineCSE, but hopefully we won't run into any issues.
Tom Tan [Fri, 31 May 2019 23:43:31 +0000 (23:43 +0000)]
[COFF, ARM64] Add CodeView register mapping
CodeView has its own register map which is defined in cvconst.h. Missing this
mapping before saving register to CodeView causes debugger to show incorrect
value for all register based variables, like variables in register and local
variables addressed by register (stack pointer + offset).
This change added mapping between LLVM register and CodeView register so the
correct register number will be stored to CodeView/PDB, it aso fixed the
mapping from CodeView register number to register name based on current
CPUType but print PDB to yaml still assumes X86 CPU and needs to be fixed.
Nick Desaulniers [Fri, 31 May 2019 23:02:13 +0000 (23:02 +0000)]
[PowerPC] check for INLINEASM_BR along w/ INLINEASM
Summary:
It looks like since INLINEASM_BR was created off of INLINEASM (r353563),
a few checks for INLINEASM needed to be updated to check for either
case.
Reid Kleckner [Fri, 31 May 2019 22:55:03 +0000 (22:55 +0000)]
[codeview] Revert inline line table change of r362264
Testing with debuggers shows that our previous behavior was correct.
The reason I thought MSVC did things differently is that MSVC prefers to
use the 0xB combined code offset and code length update opcode when
inline sites are discontiguous.
Keep the test changes, and update the llvm-pdbutil inline line table
dumper to account for this new interpretation of the opcodes.
Erik Pilkington [Fri, 31 May 2019 22:41:36 +0000 (22:41 +0000)]
[SimplifyLibCalls] Fold more fortified functions into non-fortified variants
When the object size argument is -1, no checking can be done, so calling the
_chk variant is unnecessary. We already did this for a bunch of these
functions.
projects / llvm / log