| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 297505
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: There is no need to check profile count as only CallInst will have metadata attached.
Reviewers: eraman
Reviewed By: eraman
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30799
llvm-svn: 297500
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: qcolombet, aditya_nandakumar, dsanders, ab, t.p.northover, javed.absar
Reviewed By: qcolombet
Subscribers: dberris, rovka, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D30761
llvm-svn: 297495
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts r293386, r294027, r294029 and r296411.
Turns out the SLP tree isn't actually a "tree" and we don't handle
accessing the same packet of loads in several different orders well,
causing miscompiles.
Revert until we can fix this properly.
llvm-svn: 297493
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We don’t actually use LegalizerInfo in Legalizer pass, it’s just passed
as an argument.
In order to check if an instruction is legal or not, we need to get LegalizerInfo
by calling `MI.getParent()->getParent()->getSubtarget().getLegalizerInfo()`.
Instead, make LegalizerInfo accessible in LegalizerHelper.
Reviewers: qcolombet, aditya_nandakumar, dsanders, ab, t.p.northover, kristof.beyls
Reviewed By: qcolombet
Subscribers: dberris, llvm-commits, rovka
Differential Revision: https://reviews.llvm.org/D30838
llvm-svn: 297491
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM already has real_path like functionality, but it is
cumbersome to use and involves clean up after (e.g. you have
to call openFileForRead, then close the resulting FD).
Furthermore, on Windows it doesn't work for directories since
opening a directory and opening a file require slightly
different flags.
So I add a simple function `real_path` which works for all
paths on all platforms and has a simple to use interface.
In doing so, I add the ability to opt in to resolving tilde
expressions (e.g. ~/foo), which are normally handled by
the shell.
Differential Revision: https://reviews.llvm.org/D30668
llvm-svn: 297483
|
| |
|
|
| |
llvm-svn: 297459
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We currently have to insert bits via a temporary variable of the same size as the target with various shift/mask stages, resulting in further temporary variables, all of which require the allocation of memory for large APInts (MaskSizeInBits > 64).
This is another of the compile time issues identified in PR32037 (see also D30265).
This patch adds the APInt::insertBits() helper method which avoids the temporary memory allocation and masks/inserts the raw bits directly into the target.
Differential Revision: https://reviews.llvm.org/D30780
llvm-svn: 297458
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a continuation of D28861. Add an SMLoc to MCUnaryExpr such that
a better diagnostic can be given in case of an error in later stages of
assembling.
Reviewers: rengolin, grosbach, javed.absar, olista01
Reviewed By: olista01
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30581
llvm-svn: 297454
|
| |
|
|
|
|
|
|
|
|
|
|
| |
All MIPS .debug_* sections should be marked with ELF type SHT_MIPS_DWARF
accordingly the specification [1]. Also the same section type is assigned
to these sections by GNU tools.
[1] ftp.software.ibm.com/software/os390/czos/dwarf/mips_extensions.pdf
Differential Revision: https://reviews.llvm.org/D29789
llvm-svn: 297447
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
shared between GVN and NewGVN.
Summary:
These are the functions used to determine when values of loads can be
extracted from stores, etc, and to perform the necessary insertions to
do this. There are no changes to the functions themselves except
reformatting, and one case where memdep was informed of a removed load
(which was pushed into the caller).
Reviewers: davide
Subscribers: mgorny, llvm-commits, Prazek
Differential Revision: https://reviews.llvm.org/D30478
llvm-svn: 297438
|
| |
|
|
| |
llvm-svn: 297432
|
| |
|
|
| |
llvm-svn: 297428
|
| |
|
|
|
|
| |
ImmutableCallSite abstracts away CallInst and InvokeInst. Use it!
llvm-svn: 297426
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Similar to SmallPtrSet, this makes find and count work with both const
referneces and const pointers.
Reviewers: dblaikie
Subscribers: llvm-commits, mzolotukhin
Differential Revision: https://reviews.llvm.org/D30713
llvm-svn: 297424
|
| |
|
|
|
|
| |
They're used for nefarious purposes by ObjC.
llvm-svn: 297422
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30598
llvm-svn: 297421
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30580
llvm-svn: 297406
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D27262
llvm-svn: 297398
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In a .symver assembler directive like:
.symver name, name2@@nodename
"name2@@nodename" should get the same symbol binding as "name".
While the ELF object writer is updating the symbol binding for .symver
aliases before emitting the object file, not doing so when the module
inline assembly is handled by the RecordStreamer is causing the wrong
behavior in *LTO mode.
E.g. when "name" is global, "name2@@nodename" must also be marked as
global. Otherwise, the symbol is skipped when iterating over the LTO
InputFile symbols (InputFile::Symbol::shouldSkip). So, for example,
when performing any *LTO via the gold-plugin, the versioned symbol
definition is not recorded by the plugin and passed back to the
linker. If the object was in an archive, and there were no other symbols
needed from that object, the object would not be included in the final
link and references to the versioned symbol are undefined.
The llvm-lto2 tests added will give an error about an unused symbol
resolution without the fix.
Reviewers: rafael, pcc
Reviewed By: pcc
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D30485
llvm-svn: 297332
|
| |
|
|
|
|
|
|
| |
pointer and reference types
Differential Revision: https://reviews.llvm.org/D29670
llvm-svn: 297320
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already have a function create_directories() which can create
an entire tree, and remove() which can remove an empty directory,
but we do not have remove_directories() which can remove an entire
tree. This patch adds such a function.
Because removing a directory tree can have dangerous consequences
when the tree contains a directory symlink, the patch here updates
the existing directory_iterator construct to optionally not follow
symlinks (previously it would always follow symlinks). The delete
algorithm uses this flag so that for symlinks, only the links are
removed, and not the targets.
On Windows this is implemented with SHFileOperation, which also
does not recurse into symbolic links or junctions.
Differential Revision: https://reviews.llvm.org/D30676
llvm-svn: 297314
|
| |
|
|
|
|
|
|
|
|
|
| |
To help catch buffer overruns, this patch changes BumpPtrAllocator to
insert an extra unused byte between allocations when building with
ASan. SpecificBumpPtrAllocator opts out of this behavior, since it
needs to destroy its items later by walking the allocated memory.
Reviewed by Pete Cooper.
llvm-svn: 297310
|
| |
|
|
|
|
|
|
|
|
| |
This was originall reverted due to some test failures in
ModuleCache and TestCompDirSymlink. These issues have all
been resolved and the code now passes all tests.
Differential Revision: https://reviews.llvm.org/D30698
llvm-svn: 297300
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Use AA when scanning to find an available load value.
Reviewers: rengolin, mcrosier, hfinkel, trentxintong, dberlin
Reviewed By: rengolin, dberlin
Subscribers: aemerson, dberlin, llvm-commits
Differential Revision: https://reviews.llvm.org/D30352
llvm-svn: 297284
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30638
llvm-svn: 297257
|
| |
|
|
|
|
|
|
| |
MSVC 2017 was released today, and I found one bug in the
compiler which prevents a successful build of LLVM. This
patch works around the bug in a fairly benign way.
llvm-svn: 297255
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
object that knows how to generate it.
Summary:
This will allow future patches to inspect the details of the LLT. The implementation is now split between
the Support and CodeGen libraries to allow TableGen to use this class without introducing layering concerns.
Thanks to Ahmed Bougacha for finding a reasonable way to avoid the layering issue and providing the version of this patch without that problem.
The problem with the previous commit appears to have been that TableGen was including CodeGen/LowLevelType.h instead of Support/LowLevelTypeImpl.h.
Reviewers: t.p.northover, qcolombet, rovka, aditya_nandakumar, ab, javed.absar
Subscribers: arsenm, nhaehnle, mgorny, dberris, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D30046
llvm-svn: 297241
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix SmallPtrSet::iterator behaviour and creation ReverseIterate is true.
- Any function that creates an iterator now uses
SmallPtrSet::makeIterator, which creates an iterator that
dereferences to the given pointer.
- In reverse-iterate mode, initialze iterator::End with "CurArray"
instead of EndPointer.
- In reverse-iterate mode, the current node is iterator::Buffer[-1].
iterator::operator* and SmallPtrSet::makeIterator are the only ones
that need to know.
- Fix the assertions for reverse-iterate mode.
This fixes the tests Danny B added in r297182, and adds a couple of
others to confirm that dereferencing does the right thing, regardless of
how the iterator was found, and that iteration works correctly from each
return from find.
llvm-svn: 297234
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The purpose of coro.end intrinsic is to allow frontends to mark the cleanup and
other code that is only relevant during the initial invocation of the coroutine
and should not be present in resume and destroy parts.
In landing pads coro.end is replaced with an appropriate instruction to unwind to
caller. The handling of coro.end differs depending on whether the target is
using landingpad or WinEH exception model.
For landingpad based exception model, it is expected that frontend uses the
`coro.end`_ intrinsic as follows:
```
ehcleanup:
%InResumePart = call i1 @llvm.coro.end(i8* null, i1 true)
br i1 %InResumePart, label %eh.resume, label %cleanup.cont
cleanup.cont:
; rest of the cleanup
eh.resume:
%exn = load i8*, i8** %exn.slot, align 8
%sel = load i32, i32* %ehselector.slot, align 4
%lpad.val = insertvalue { i8*, i32 } undef, i8* %exn, 0
%lpad.val29 = insertvalue { i8*, i32 } %lpad.val, i32 %sel, 1
resume { i8*, i32 } %lpad.val29
```
The `CoroSpit` pass replaces `coro.end` with ``True`` in the resume functions,
thus leading to immediate unwind to the caller, whereas in start function it
is replaced with ``False``, thus allowing to proceed to the rest of the cleanup
code that is only needed during initial invocation of the coroutine.
For Windows Exception handling model, a frontend should attach a funclet bundle
referring to an enclosing cleanuppad as follows:
```
ehcleanup:
%tok = cleanuppad within none []
%unused = call i1 @llvm.coro.end(i8* null, i1 true) [ "funclet"(token %tok) ]
cleanupret from %tok unwind label %RestOfTheCleanup
```
The `CoroSplit` pass, if the funclet bundle is present, will insert
``cleanupret from %tok unwind to caller`` before
the `coro.end`_ intrinsic and will remove the rest of the block.
Reviewers: majnemer
Reviewed By: majnemer
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D25543
llvm-svn: 297223
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Broadcom Vulcan is now Cavium ThunderX2T99.
LLVM Bugzilla: http://bugs.llvm.org/show_bug.cgi?id=32113
Minor fixes for the alignments of loops and functions for
ThunderX T81/T83/T88 (better performance).
Patch was tested with SpecCPU2006.
Patch by Stefan Teleman
Differential Revision: https://reviews.llvm.org/D30510
llvm-svn: 297190
|
| |
|
|
|
|
|
|
|
|
| |
More module problems. This time it only showed up in the stage 2 compile of
clang-x86_64-linux-selfhost-modules-2 but not the stage 1 compile.
Somehow, this change causes the build to need Attributes.gen before it's been
generated.
llvm-svn: 297188
|
| |
|
|
|
|
| |
In DWARF5 the Unit header added a new field, UnitType, and swapped the order of the address size and abbreviation offset fields.
llvm-svn: 297183
|
| |
|
|
|
|
| |
non-const version. Clang and other users have a number of types they use as pointers, and this avoids having to define both const and non-const versions of PointerLikeTraits.
llvm-svn: 297181
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For our set/map types, count/find normally take const references.
This works well for non-pointer types, but can suck for pointer
types.
DenseSet<int *> foo;
const int *b = nullptr;
foo.count(b) does not work
but the equivalent reference version does work
(patch to fix DenseSet/DenseMap coming up)
For SmallPtrSet, you have no such option.
The following will not work right now:
SmallPtrSet<int *> foo;
const int *b = nullptr;
foo.count(b);
This makes const correctness hard in some cases.
Example:
SmallPtrSet<Instruction *> InstructionsToErase;
You can't make this SmallPtrSet<const Instruction *> because then you
can't erase the instruction. If I want to see if something is in the
set, I may only have a const Instruction *. Given that count and find
are non-mutating, this should just work.
The places in our code base that do this resort to const_cast :(.
This patch makes count and find able to be used with const Instruction
* in the above SmallPtrSet examples.
This is a bit annoying because of where C++ applies the const, so we
have to remove the pointer type from the passed-in-type and rebuild it
with const.
Reviewers: dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30608
llvm-svn: 297180
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
knows how to generate it.
Summary:
This will allow future patches to inspect the details of the LLT. The implementation is now split between
the Support and CodeGen libraries to allow TableGen to use this class without introducing layering concerns.
Thanks to Ahmed Bougacha for finding a reasonable way to avoid the layering issue and providing the version of this patch without that problem.
Reviewers: t.p.northover, qcolombet, rovka, aditya_nandakumar, ab, javed.absar
Subscribers: arsenm, nhaehnle, mgorny, dberris, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D30046
llvm-svn: 297177
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: qcolombet, javed.absar, aditya_nandakumar, dsanders, t.p.northover, ab
Reviewed By: qcolombet
Subscribers: dberris, rovka, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D30671
llvm-svn: 297171
|
| |
|
|
| |
llvm-svn: 297154
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
other""
The original patch r296865 was reverted as it broke the chromium builds for
Android https://bugs.llvm.org/show_bug.cgi?id=32134, this patch reapplies
r296865 with a fix to make sure it doesn't cause the build regression.
The problem was that intrinsic selection on int_arm_get_fpscr was failing in
ISel this was because the code to manually select this intrinsic still thought
it was the version with no side-effects (INTRINSIC_WO_CHAIN) which is wrong as
it doesn't semantically match the definition in the tablegen code which says it
does have side-effects, I've fixed this by updating the intrinsic type to
INTRINSIC_W_CHAIN (has side-effects). I've also added a test for this based on
Hans original reproducer.
Differential Revision: https://reviews.llvm.org/D30645
llvm-svn: 297137
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
their memory allocation to be reused when possible
This extends an earlier change that did similar for add and sub operations.
With this first patch we lose the fastpath for the single word case as operator&= and friends don't support it. This can be added there if we think that's important.
I had to change some functions in the APInt class since the operator overloads were moved out of the class and can't be used inside the class now. The getBitsSet change collides with another outstanding patch to implement it with setBits. But I didn't want to make this patch dependent on that series.
I've also removed the Or, And, Xor functions which were rarely or never used. I already commited two changes to remove the only uses of Or that existed.
Differential Revision: https://reviews.llvm.org/D30612
llvm-svn: 297121
|
| |
|
|
|
|
|
|
|
|
| |
This deletes LLDB's FileType enumeration and replaces all
users, and all calls to functions that check whether a file
exists etc with corresponding calls to LLVM.
Differential Revision: https://reviews.llvm.org/D30624
llvm-svn: 297116
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We currently have methods to set a specified number of low bits, a specified number of high bits, or a range of bits. But looking at some existing code it seems sometimes we want to set the high bits starting from a certain bit. Currently we do this with something like getHighBits(BitWidth, BitWidth - StartBit). Or once we start switching to setHighBits, setHighBits(BitWidth - StartBit) or setHighBits(getBitWidth() - StartBit).
Particularly for the latter case it would be better to have a convenience method like setBitsFrom(StartBit) so we don't need to mention the bit width that's already known to the APInt object.
I considered just making setBits have a default value of UINT_MAX for the hiBit argument and we would internally MIN it with the bit width. So if it wasn't specified it would be treated as bit width. This would require removing the assertion we currently have on the value of hiBit and may not be as readable.
Differential Revision: https://reviews.llvm.org/D30602
llvm-svn: 297114
|
| |
|
|
|
|
|
|
|
|
|
|
| |
setLowBits/setHighBits/setBits
This patch implements getLowBitsSet/getHighBitsSet/getBitsSet in terms of the new setLowBits/setHighBits/setBits methods by making an all 0s APInt and then calling the appropriate set method.
This also adds support to setBits to allow loBits/hiBits to be in the other order to match with getBitsSet behavior.
Differential Revision: https://reviews.llvm.org/D30563
llvm-svn: 297112
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There are quite a few places in the code base that do something like the following to set the high or low bits in an APInt.
KnownZero |= APInt::getHighBitsSet(BitWidth, BitWidth - 1);
For BitWidths larger than 64 this creates a short lived APInt with malloced storage. I think it might even call malloc twice. Its better to just provide methods that can set the necessary bits without the temporary APInt.
I'll update usages that benefit in a separate patch.
Reviewers: majnemer, MatzeB, davide, RKSimon, hans
Reviewed By: hans
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30525
llvm-svn: 297111
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to my change in r295090, which added support for
disabling these checks selectively based on setting the preprocessor
macro without relying on the Cmake setting. Swift has moved over to use
that approach, so we can clean up here and remove the Cmake setting.
https://reviews.llvm.org/D30578
llvm-svn: 297109
|
| |
|
|
|
|
| |
Details and reproducer are on the email thread for r296863.
llvm-svn: 297103
|
| |
|
|
|
|
|
| |
A bit more painful than G_INSERT because it was more widely used, but this
should simplify the handling of extract operations in most locations.
llvm-svn: 297100
|
| |
|
|
|
|
|
|
| |
This patch adds support to the DWARF YAML reader and writer for the new DWARF5 abbreviation form, DW_FORM_implicit_const.
The attribute was added in r291599.
llvm-svn: 297091
|
| |
|
|
| |
llvm-svn: 297088
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Some late additions to DWARF v5 were not in Dwarf.def; also one form
was redefined. Add the new cases to relevant switches in different
parts of LLVM. Replace DW_FORM_ref_sup with DW_FORM_ref_sup[4,8].
I did not add support for DW_FORM_strx3/addrx3 other that defining the
constants. We don't have any infrastructure to support these.
Differential Revision: http://reviews.llvm.org/D30664
llvm-svn: 297085
|