| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 283008
|
| |
|
|
| |
llvm-svn: 283007
|
| |
|
|
| |
llvm-svn: 283005
|
| |
|
|
| |
llvm-svn: 283004
|
| |
|
|
|
|
|
| |
This reverts commit r282999.
Tests are not passing: http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/20038
llvm-svn: 283003
|
| |
|
|
|
|
| |
of the TargetMachine. NFC.
llvm-svn: 283002
|
| |
|
|
|
|
| |
TargetTriple, just grab it off of the TargetMachine. NFC.
llvm-svn: 283001
|
| |
|
|
|
|
| |
and can be pulled from the TargetMachine. NFC.
llvm-svn: 283000
|
| |
|
|
|
|
| |
This removes many re-initializations of a base register to 0.
llvm-svn: 282999
|
| |
|
|
| |
llvm-svn: 282998
|
| |
|
|
| |
llvm-svn: 282997
|
| |
|
|
| |
llvm-svn: 282996
|
| |
|
|
|
|
| |
the corpus smaller, off by default
llvm-svn: 282995
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To lex hash directives we peek ahead to find component tokens, create a
unified token, and unlex the peeked tokens so the parser does not need
to parse the tokens then. Make sure we do not to lex another hash
directive during peek operation.
This fixes PR28921.
Reviewers: rnk, loladiro
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24839
llvm-svn: 282992
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dead-stripping
The binder is in a specific section that "reverse" the edges in a
regular dead-stripping: the binder is live as long as a global it
references is live.
This is a big hammer that prevents LLVM from dead-stripping these,
while still allowing linker dead-stripping (with special knowledge
of the section).
Differential Revision: https://reviews.llvm.org/D24673
llvm-svn: 282988
|
| |
|
|
| |
llvm-svn: 282983
|
| |
|
|
| |
llvm-svn: 282979
|
| |
|
|
|
|
| |
installed
llvm-svn: 282972
|
| |
|
|
| |
llvm-svn: 282971
|
| |
|
|
|
|
|
|
|
| |
This avoids errors about references to undefined local labels from
unreferenced filter functions.
Fixes (sort of) PR30431
llvm-svn: 282967
|
| |
|
|
|
|
|
|
| |
This makes sure the helper functions work as expected.
NFC.
llvm-svn: 282961
|
| |
|
|
|
|
|
|
| |
We don't return index, we return the actual ValueMapping.
NFC.
llvm-svn: 282960
|
| |
|
|
|
|
|
|
|
|
| |
We don't need to have singleton ValueMapping on their own, we can just
reuse one of the elements of the 3-ops mapping.
This allows even more code sharing.
NFC.
llvm-svn: 282959
|
| |
|
|
|
|
|
|
|
| |
Use a helper function to access ValMapping. This should make the code
easier to understand and maintain.
NFC.
llvm-svn: 282958
|
| |
|
|
|
|
|
|
|
| |
The function name did not make it clear that the returned value was an
offset to apply to a register bank index.
NFC.
llvm-svn: 282957
|
| |
|
|
|
|
|
|
| |
Avoid to rely on the dynamically allocated operands mapping for the
alternative mapping.
NFC.
llvm-svn: 282956
|
| |
|
|
| |
llvm-svn: 282954
|
| |
|
|
| |
llvm-svn: 282952
|
| |
|
|
| |
llvm-svn: 282950
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we create a PDB file using PDBFileBuilder, the information
in the superblock, such as the size of the resulting file, is not
available.
Previously, PDBFileBuilder::initialize took a superblock assuming
that all the members of the struct are correct. That is useful when
you want to restore the exact information from a YAML file, but
that's probably the only use case in which that is useful.
When we are creating a PDB file on the fly, we have to backfill the
members.
This patch redefines PDBFileBuilder::initialize to take only a
block size. Now all the other members are left as default values,
so that they'll be updated when commit() is called.
Differential Revision: https://reviews.llvm.org/D25108
llvm-svn: 282944
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WritableStream needs the exact file size to open a file, but
until we fix the final layout of a PDB file, we don't know the
size of the file.
This patch changes the parameter type of PDBFileBuilder::commit
to solve that chiecken-and-egg problem. Now the function opens
a file after fixing the layout, so it can create a file with the
exact size.
Differential Revision: https://reviews.llvm.org/D25107
llvm-svn: 282940
|
| |
|
|
|
|
| |
to check for the former, don't depend on (dangling) HAVE_MMAP_ANONYMOUS.
llvm-svn: 282925
|
| |
|
|
|
|
|
| |
systems. It wasn't even hooked up in cmake, so problems on such systems
would be visible with 3.9 release already.
llvm-svn: 282924
|
| |
|
|
|
|
|
|
|
|
|
| |
We can't use Jcc to leave a Win64 function in general, because that
confuses the unwinder. However, for "leaf" functions, that is, functions
where the return address is always on top of the stack and which don't
have unwind info, it's OK.
Differential Revision: https://reviews.llvm.org/D24836
llvm-svn: 282920
|
| |
|
|
| |
llvm-svn: 282919
|
| |
|
|
| |
llvm-svn: 282918
|
| |
|
|
| |
llvm-svn: 282906
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
coro.save and coro.suspend
Summary:
In the case below, %Result.i19 is defined between coro.save and coro.suspend and used after coro.suspend. We need to correctly place such a value into the coroutine frame.
```
%save = call token @llvm.coro.save(i8* null)
%Result.i19 = getelementptr inbounds %"struct.lean_future<int>::Awaiter", %"struct.lean_future<int>::Awaiter"* %ref.tmp7, i64 0, i32 0
%suspend = call i8 @llvm.coro.suspend(token %save, i1 false)
switch i8 %suspend, label %exit [
i8 0, label %await.ready
i8 1, label %exit
]
await.ready:
%val = load i32, i32* %Result.i19
```
Reviewers: majnemer
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D24418
llvm-svn: 282902
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Without the fix, if there was a function inlined into the coroutine with debug information, CloneFunctionInto(NewF, &F, VMap, /*ModuleLevelChanges=*/true, Returns); would duplicate all of the debug information including the DICompileUnit.
We know use VMap to indicate that debug metadata for a File, Unit and FunctionType should not be duplicated when we creating clones that will become f.resume, f.destroy and f.cleanup.
Reviewers: majnemer
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D24417
llvm-svn: 282899
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Not all coro.subfn.addr intrinsics can be eliminated in CoroElide through devirtualization. Those that remain need to be lowered in CoroCleanup.
Reviewers: majnemer
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D24412
llvm-svn: 282897
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
optimization decisions.
Summary: Debug info should *not* affect optimization decisions. This patch updates loop unroller cost model to make it not affected by debug info.
Reviewers: davidxl, mzolotukhin
Subscribers: haicheng, llvm-commits, mzolotukhin
Differential Revision: https://reviews.llvm.org/D25098
llvm-svn: 282894
|
| |
|
|
| |
llvm-svn: 282892
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Register stackification currently checks VNInfo for changes. Make that
more accurate by testing each intervening instruction for any other defs
to the same virtual register.
Patch by Jacob Gravelle
Differential Revision: https://reviews.llvm.org/D24942
llvm-svn: 282886
|
| |
|
|
| |
llvm-svn: 282884
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is adding the support for a shadow memory with
dynamically allocated address range.
The compiler-rt needs to export a symbol containing the shadow
memory range.
This is required to support ASAN on windows 64-bits.
Reviewers: kcc, rnk, vitalybuka
Subscribers: zaks.anna, kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D23354
llvm-svn: 282881
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D24973
llvm-svn: 282877
|
| |
|
|
|
|
|
|
| |
instruction
Differential Revision: https://reviews.llvm.org/D24985
llvm-svn: 282875
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D25055
llvm-svn: 282873
|
| |
|
|
|
|
| |
With 282650 in tree extra no wrap on adds doesn't cause regressions anymore. Reenable the optimzation.
llvm-svn: 282872
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building the steps for scalar induction variables, we previously attempted
to determine if all the scalar users of the induction variable were uniform. If
they were, we would only emit the step corresponding to vector lane zero. This
optimization was too aggressive. We generally don't know the entire set of
induction variable users that will be scalar. We have
isScalarAfterVectorization, but this is only a conservative estimate of the
instructions that will be scalarized. Thus, an induction variable may have
scalar users that aren't already known to be scalar. To avoid emitting unused
steps, we can only check that the induction variable is uniform. This should
fix PR30542.
Reference: https://llvm.org/bugs/show_bug.cgi?id=30542
llvm-svn: 282863
|