| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
(https://hermitcore.org) ELF binaries.
HermitCore is a POSIX-compatible kernel for running a single application in an isolated environment to get maximum performance and predictable runtime behavior. It can either be used bare-metal on hardware or a VM (Unikernel) or side by side to an existing Linux system (Multikernel).
Due to the latter feature, HermitCore binaries are marked with ELFOSABI_STANDALONE to let the Linux ELF loader distinguish them from regular Unix/Linux binaries and load them using the HermitCore "proxy" tool.
Patch by Colin Finck!
llvm-svn: 340675
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Missing check for isImm() in some Immediate classes.
This bug was uncovered by a LLVM MC Assembler Protocol Buffer Fuzzer
for the RISC-V assembly language.
Reviewers: hiraditya, asb
Reviewed By: hiraditya, asb
Subscribers: llvm-commits, hiraditya, kito-cheng, shiva0217, rkruppe, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, zzheng, edward-jones, mgrang, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei
Differential Revision: https://reviews.llvm.org/D50797
llvm-svn: 340674
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function's new implementation from r340583 had a bug in it that
could cause an invalid scope to be generated when merging two
DILocations with no common ancestor scope.
This patch detects this situation and picks the scope of the first
location. This is not perfect, because the scope is misleading, but on
the other hand, this will be a line 0 location.
rdar://problem/43687474
Differential Revision: https://reviews.llvm.org/D51238
llvm-svn: 340672
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
demangling process when it does.
Use this to support a "lookup" query for the mangling canonicalizer that
does not create new nodes. This could also be used to implement
demangling with a fixed-size temporary storage buffer.
Reviewers: erik.pilkington
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D51003
llvm-svn: 340670
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It seems std::advance template is treating "-MFI.getCalleeSavedInfo().size()"
as a large unsigned value", causing slowness.
Thanks to Henrik Gustafsson for reporting the issue.
Reviewers: asb
Reviewed By: asb
Subscribers: llvm-commits, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, asb
Differential Revision: https://reviews.llvm.org/D51148
llvm-svn: 340669
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Given a set of equivalent name fragments, this mechanism determines whether two
mangled names are equivalent. The intent is to use this for fuzzy matching of
profile data against the program after certain refactorings are performed.
Reviewers: erik.pilkington, dlj
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D50935
llvm-svn: 340663
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D51193
llvm-svn: 340657
|
|
|
|
| |
llvm-svn: 340655
|
|
|
|
| |
llvm-svn: 340654
|
|
|
|
|
|
|
|
| |
This fixes an assertion failure(!) in the Verifier.
rdar://problem/43687474
llvm-svn: 340653
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise, the debug info is incorrect. On its own, this is mostly
harmless, but the safe-stack also later inlines the call to
__safestack_pointer_address, which leads to debug info with the wrong
scope, which eventually causes an assertion failure (and incorrect debug
info in release mode).
Differential Revision: https://reviews.llvm.org/D51075
llvm-svn: 340651
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
address-significance table.
Firstly, require the symbol to be used within the module. If a
symbol is unused within a module, then by definition it cannot be
address-significant within that module. This condition is useful on all
platforms because it could make symbol tables smaller -- without this
change, emitting an address-significance table could cause otherwise
unused undefined symbols to be added to the object file.
But this change is necessary with COFF specifically in order to
preserve the property that an unreferenced undefined symbol in an IR
module does not result in a link failure. This is already the case for
ELF because ELF linkers only reject links with unresolved symbols if
there is a relocation to that symbol, but COFF linkers require all
undefined symbols to be resolved regardless of relocations. So if
a module contains an unreferenced undefined symbol, we need to make
sure not to add it to the address-significance table (and thus the
symbol table) in case it doesn't end up resolved at link time.
Secondly, do not add dllimport symbols to the table. These symbols
won't be able to be resolved because their definitions live in another
module and are accessed via the IAT, and the address-significance
table has no effect on other modules anyway. It wouldn't make sense
to add the IAT entry symbol to the address-significance table either
because the IAT entry isn't address-significant -- the generated code
never takes its address.
Differential Revision: https://reviews.llvm.org/D51199
llvm-svn: 340648
|
|
|
|
|
|
|
|
|
|
| |
My previoust test case had skipped CUs from one TU out of a two-TU LTO
scenario, which meant the CU index wasn't needed (as it was unambiguous
which CU a table entry applied to) - expanding the test to use 3 TUs,
skipping one (so long as it's not the last one) shows the indexes are
miscomputed. Fix that with a little indirection for the index.
llvm-svn: 340646
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
registers for P9
This patch will address using the xscpsgndp instruction to copy floating point
scalar registers instead of the xxlor (specifically XXLORf) instruction that is
currently used. Additionally, this patch of utilizing xscpsgndp will apply to
P9, while pre-P9 will still use xxlor.
Patch by amyk
Differential Revision: https://reviews.llvm.org/D50004
llvm-svn: 340643
|
|
|
|
| |
llvm-svn: 340642
|
|
|
|
| |
llvm-svn: 340638
|
|
|
|
|
|
|
|
| |
Otherwise, we would crash trying to deal with an illegal input.
Differential Revision: https://reviews.llvm.org/D51202
llvm-svn: 340637
|
|
|
|
|
|
|
|
| |
mapping
Differential Revision: https://reviews.llvm.org/D51095
llvm-svn: 340634
|
|
|
|
|
|
|
|
| |
and the add has two multiply inputs
Differential Revision: https://reviews.llvm.org/D50868
llvm-svn: 340631
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the store is volatile, if the resulting store isn't Legal
Previously we allowed the store to be Custom. But without knowing for sure that the Custom handling won't split the store, we shouldn't convert a volatile store. We also probably shouldn't be creating a store the requires custom handling after LegalizeOps. This could lead to an infinite loop if the custom handling was to insert a bitcast. Though I guess isStoreBitCastBeneficial could be used to block such a loop.
The test changes here are due to the volatile part of this. The stores in the test are all volatile and i32 stores are marked custom, So we are no longer converting them
This is related to D50491 where I was trying to allow some bitcasting of volatile loads
Differential Revision: https://reviews.llvm.org/D50578
llvm-svn: 340626
|
|
|
|
| |
llvm-svn: 340619
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Sometimes reading an output *.ll file it is not easy to understand why some callsites are not inlined. We can read output of inline remarks (option --pass-remarks-missed=inline) and try correlating its messages with the callsites.
An easier way proposed by this patch is to add to every callsite processed by Inliner an attribute with the latest message that describes the cause of not inlining this callsite. The attribute is called //inline-remark//. By default this feature is off. It can be switched on by the option //-inline-remark-attribute//.
For example in the provided test the result method //@test1// has two callsites //@bar// and inline remarks report different inlining missed reasons:
remark: <unknown>:0:0: bar not inlined into test1 because too costly to inline (cost=-5, threshold=-6)
remark: <unknown>:0:0: bar not inlined into test1 because it should never be inlined (cost=never): recursive
It is not clear which remark correspond to which callsite. With the inline remark attribute enabled we get the reasons attached to their callsites:
define void @test1() {
call void @bar(i1 true) #0
call void @bar(i1 false) #2
ret void
}
attributes #0 = { "inline-remark"="(cost=-5, threshold=-6)" }
..
attributes #2 = { "inline-remark"="(cost=never): recursive" }
Patch by: yrouban (Yevgeny Rouban)
Reviewers: xbolva00, tejohnson, apilipenko
Reviewed By: xbolva00, tejohnson
Subscribers: eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D50435
llvm-svn: 340618
|
|
|
|
|
|
|
|
|
|
| |
before it
Once the invariant_start is reached, we know that no instruction *after* it can modify the memory. So, if we can prove the location isn't read *between entry into the loop and the execution of the invariant_start*, we can execute the invariant_start before entering the loop.
Differential Revision: https://reviews.llvm.org/D51181
llvm-svn: 340617
|
|
|
|
| |
llvm-svn: 340615
|
|
|
|
|
|
|
|
|
|
|
| |
The way that PhiValues is integrated with BasicAA it is possible for a pass
which uses BasicAA to pick up an instance of BasicAA that uses PhiValues without
intending to, and then delete values from a function in a way that causes
PhiValues to return dangling pointers to these deleted values. Fix this by
having a set of callback value handles to invalidate values when they're
deleted.
llvm-svn: 340613
|
|
|
|
|
|
|
|
|
|
| |
This adds a new method to ELFObjectFileBase that returns the symbols and addresses of PLT entries.
This design was suggested by pcc and eugenis in https://reviews.llvm.org/D49383.
Differential Revision: https://reviews.llvm.org/D50203
llvm-svn: 340610
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes the DoesKMove argument non-optional, to force people
to think about it. Most cases where it is false are either code hoisting
or code sinking, where we pick one instruction from a set of
equal instructions among different code paths.
Reviewers: dberlin, nlopes, efriedma, davide
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D47475
llvm-svn: 340606
|
|
|
|
|
|
|
|
|
|
| |
This patch splits the file trace loading function into two versions, one
that takes a filename and one that takes a `DataExtractor`.
This change is a precursor to larger changes to increase test coverage
for the trace loading implementation.
llvm-svn: 340603
|
|
|
|
|
|
|
|
|
|
|
| |
Having the KnownBits as an output parameter is kind of awkward to use
and a holdover from when it was two separate APInts. Instead, just
return a KnownBits object.
I'm leaving the existing interface in place for now, since updating
the callers all at once would be thousands of lines of diff.
llvm-svn: 340594
|
|
|
|
|
|
|
| |
That way users can set the default to true, but then disable core dumps
from certain apps that link support.
llvm-svn: 340588
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a set of related bugs:
* Considering two locations as equivalent when their lines are the same
but their scopes are different causes erroneous debug info that
attributes a commoned call to be attributed to one of the two calls it
was commoned from.
* The previous code to compute a new location's scope was inaccurate and
would use the inlinedAt that was the /parent/ of the inlinedAt that is
the nearest common one, and also used that parent scope instead of the
nearest common scope.
* Not generating new locations generally seemed like a lower quality
choice
There was some risk that generating more new locations could hurt object
size by making more fine grained line table entries, but it looks like
that was offset by the decrease in line table (& address & ranges) size
caused by more accurately computing the scope - which likely lead to
fewer range entries (more contiguous ranges) & reduced size that way.
All up with these changes I saw minor reductions (-1.21%, -1.77%) in
.rela.debug_ranges and .rela.debug_addr (in a fission, compressed debug
info build) as well as other minor size changes (generally reductinos)
across the board (-1.32% debug_info.dwo, -1.28% debug_loc.dwo). Measured
in an optimized (-O2) build of the clang binary.
If you are investigating a size regression in an optimized debug builds,
this is certainly a patch to look into - and I'd be happy to look into
any major regressions found & see what we can do to address them.
llvm-svn: 340583
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lower integer arguments smaller than i32.
Support both register and stack arguments.
Define setLocInfo function for setting LocInfo field in ArgLocs vector.
Patch by Petar Avramovic.
Differential Revision: https://reviews.llvm.org/D51031
llvm-svn: 340572
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Splats are fewer bytes than v128.consts, so use them when either could
apply.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D51179
llvm-svn: 340569
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Avoid "count" if possible -> use "find" to check for the existence of keys.
Passed llvm test suite.
Reviewers: fhahn, dcaballe, mkuper, rengolin
Reviewed By: fhahn
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D51054
llvm-svn: 340563
|
|
|
|
|
|
|
|
|
| |
secondly coreFilesPrevented.
The previous change ignored the latter resulting in crash dumps being generated when LLVM_ENABLE_CRASH_DUMPS was
set, but coreFilesPrevented was true.
llvm-svn: 340561
|
|
|
|
|
|
| |
The bug was already fixed. This just adds a test case for it.
llvm-svn: 340556
|
|
|
|
| |
llvm-svn: 340553
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I got "Use not jointly dominated by defs" when removePartialRedundancy
attempted to prune then re-extend a subrange whose only liveness was a
dead def at the copy being removed.
V2: Removed junk from test. Improved comment.
V3: Addressed minor review comments.
Subscribers: MatzeB, qcolombet, nhaehnle, llvm-commits
Differential Revision: https://reviews.llvm.org/D50914
Change-Id: I6f894e9f517f71e921e0c6d81d28c5f344db8dad
llvm-svn: 340549
|
|
|
|
|
|
|
|
|
|
| |
We need to allow ConstantExpr Selects in addition to SelectInst.
I'll try to put together a test case, but I wanted to fix the issues being reported.
Fixes PR38677
llvm-svn: 340546
|
|
|
|
|
|
|
|
|
|
|
|
| |
The commit that added this functionality:
rL322957
may be causing/exposing a miscompile in PR38648:
https://bugs.llvm.org/show_bug.cgi?id=38648
so allow enabling/disabling to make debugging easier.
llvm-svn: 340540
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Follow up for https://reviews.llvm.org/rL339520 and https://reviews.llvm.org/rL338300
Alive:
```
%A = fcmp oeq float %x, 0.0
%B = fadd nsz float %x, %z
%C = select i1 %A, float %B, float %y
=>
%C = select i1 %A, float %z, float %y
----------
%A = fcmp oeq float %x, 0.0
%B = fadd nsz float %x, %z
%C = select %A, float %B, float %y
=>
%C = select %A, float %z, float %y
Done: 1
Optimization is correct
%A = fcmp une float %x, -0.0
%B = fadd nsz float %x, %z
%C = select i1 %A, float %y, float %B
=>
%C = select i1 %A, float %y, float %z
----------
%A = fcmp une float %x, -0.0
%B = fadd nsz float %x, %z
%C = select %A, float %y, float %B
=>
%C = select %A, float %y, float %z
Done: 1
Optimization is correct
```
Reviewers: spatel, lebedev.ri
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50714
llvm-svn: 340538
|
|
|
|
|
|
|
|
|
|
|
|
| |
These changes expand the FunctionAttr logic in order to mark functions as
WriteOnly when appropriate. This is done through an additional bool variable
and extended logic.
Reviewers: hfinkel, jdoerfert
Differential Revision: https://reviews.llvm.org/D48387
llvm-svn: 340537
|
|
|
|
|
|
|
|
|
|
| |
When GVN sets the incoming value for a phi to undef because the incoming block
is unreachable it needs to also invalidate the cached info for that phi in
MemoryDependenceAnalysis, otherwise later queries will return stale information.
Differential Revision: https://reviews.llvm.org/D51099
llvm-svn: 340529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both DWARFDebugLine and DWARFDebugAddr used the same callback mechanism
for handling recoverable errors. They both implemented similar warn() function
to be used as such callbacks.
In this revision we get rid of code duplication and move this warn() function
to DWARFContext as DWARFContext::dumpWarning().
Reviewers: lhames, jhenderson, aprantl, probinson, dblaikie, JDevlieghere
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D51033
llvm-svn: 340528
|
|
|
|
| |
llvm-svn: 340526
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instructions.
This version of the patch fixes cleaning up ssa_copy intrinsics, so it does not
crash for instructions in blocks that have been marked unreachable.
This patch updates IPSCCP to use PredicateInfo to propagate
facts to true branches predicated by EQ and to false branches
predicated by NE.
As a follow up, we should be able to extend it to also propagate additional
facts about nonnull.
Reviewers: davide, mssimpso, dberlin, efriedma
Reviewed By: davide, dberlin
Differential Revision: https://reviews.llvm.org/D45330
llvm-svn: 340525
|
|
|
|
|
|
|
|
|
|
| |
For the _WIN32 macro, it is the definedness that matters rather than
the value. Most uses of the macro already rely on the definedness.
This commit fixes the few remaining uses that relied on the value.
Differential Revision: https://reviews.llvm.org/D51105
llvm-svn: 340520
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most users won't have to worry about this as all of the
'getOrInsertFunction' functions on Module will default to the program
address space.
An overload has been added to Function::Create to abstract away the
details for most callers.
This is based on https://reviews.llvm.org/D37054 but without the changes to
make passing a Module to Function::Create() mandatory. I have also added
some more tests and fixed the LLParser to accept call instructions for
types in the program address space.
Reviewed By: bjope
Differential Revision: https://reviews.llvm.org/D47541
llvm-svn: 340519
|
|
|
|
|
|
|
|
|
| |
This fragment is created after layout, which is where the order
normally gets set.
Should fix a test failure under msan.
llvm-svn: 340516
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
subtarget features for indirect calls and indirect branches.
This is in preparation for enabling *only* the call retpolines when
using speculative load hardening.
I've continued to use subtarget features for now as they continue to
seem the best fit given the lack of other retpoline like constructs so
far.
The LLVM side is pretty simple. I'd like to eventually get rid of the
old feature, but not sure what backwards compatibility issues that will
cause.
This does remove the "implies" from requesting an external thunk. This
always seemed somewhat questionable and is now clearly not desirable --
you specify a thunk the same way no matter which set of things are
getting retpolines.
I really want to keep this nicely isolated from end users and just an
LLVM implementation detail, so I've moved the `-mretpoline` flag in
Clang to no longer rely on a specific subtarget feature by that name and
instead to be directly handled. In some ways this is simpler, but in
order to preserve existing behavior I've had to add some fallback code
so that users who relied on merely passing -mretpoline-external-thunk
continue to get the same behavior. We should eventually remove this
I suspect (we have never tested that it works!) but I've not done that
in this patch.
Differential Revision: https://reviews.llvm.org/D51150
llvm-svn: 340515
|