Summary:
AIX system headers need stdint.h and inttypes.h to be re-enterable when macro _STD_TYPES_T is defined so that limit macro definitions such as UINT32_MAX can be found. This patch attempts to allow that on AIX.
Reviewers: hubert.reinterpretcast, jasonliu, mclow.lists, EricWF
Reviewed by: hubert.reinterpretcast, mclow.lists
Subscribers: jfb, jsji, christof, cfe-commits, libcxx-commits, llvm-commits
Tags: #LLVM, #clang, #libc++
Differential Revision: https://reviews.llvm.org/D59253
llvm-svn: 363939
This includes integer arithmetic of various kinds (add/sub/multiply,
saturating and not), and the immediate forms of VMOV and VMVN that
load an immediate into all lanes of a vector.
Reviewers: dmgreen, samparker, SjoerdMeijer, t.p.northover
Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62674
llvm-svn: 363936
AMDGPU target needs to override getRegClass() used during
instruction selection. We now may have either 32 or 64 bit
conditional registers used in the same instructions. For
that purpose special SReg_1 register class is created which
is dynamically resolved to either SReg_64 or SGPR_32 depending
on the subtarget attributes.
Differential Revision: https://reviews.llvm.org/D63205
llvm-svn: 363931
ELFState<ELFT>::addSymbols method looks a bit strange.
User code have to create the destination symbols vector outside,
add a null symbol and then pass it to addSymbols when it seems
the more natural logic is to isolate all work with symbols inside some
function, build the list right there and return it.
Differential revision: https://reviews.llvm.org/D63493
llvm-svn: 363930
Summary:
Our rule to create R_*_RELATIVE for absolute relocation types were
loose. D63121 made it stricter but it failed to create R_*_RELATIVE for
R_ARM_TARGET1 and R_PPC64_TOC. rLLD363236 worked around that by
reinstating the original behavior for ARM and PPC64.
This patch is an attempt to simplify the logic.
Note, in ld.bfd, R_ARM_TARGET2 --target2=abs also creates
R_ARM_RELATIVE. This seems a very uncommon scenario (moreover,
--target2=got-rel is the default), so I do not implement any logic
related to it.
Also, delete R_AARCH64_ABS32 from AArch64::getDynRel. We don't have
working ILP32 support yet. Allowing it would create an incorrect
R_AARCH64_RELATIVE.
For MIPS, the (if SymbolRel, then RelativeRel) code is to keep its
behavior unchanged.
Note, in ppc64-abs64-dyn.s, R_PPC64_TOC gets an incorrect addend because
computeAddend() doesn't compute the correct address. We seem to have the
wrong behavior for a long time. The important thing seems that a dynamic
relocation R_PPC64_TOC should not be created as the dynamic loader will
error R_PPC64_TOC is not supported.
Reviewers: atanasyan, grimar, peter.smith, ruiu, sfertile, espindola
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63383
llvm-svn: 363928
ARM and RISC-V do not support TLS relaxations. However, for General
Dynamic and Local Dynamic models, if we are producing an executable and
the symbol is non-preemptable, we know it must be defined and the
R_ARM_TLS_DTPMOD32/R_RISCV_TLS_DTPMOD{32,64} dynamic relocation can be
omitted because it is always 1. This may be necessary for static linking
as DTPMOD may not be expected at load time.
Merge handleARMTlsRelocation() into handleTlsRelocation(). This requires
more logic to R_TLSGD_PC and R_TLSLD_PC. Because we use SymbolicRel to
resolve the relocation at link time, R_ARM_TLS_DTPMOD32 can be deleted
from relocateOne(). It cannot be used as a static relocation type.
As a bonus, the additional logic in R_TLSGD_PC code can be shared by the
TLS support for RISC-V (D63220).
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63333
llvm-svn: 363927
We tend to only test for scalar/scalar consts when really we could support non-uniform vectors using ISD::matchUnaryPredicate/matchBinaryPredicate etc.
llvm-svn: 363924
Remove most of the abstraction over ptrace() register operations,
as it has little value and introduces more code than it saves.
Instead, leave a single ptrace() wrapper method and call it directly
from ReadRegisterSet() and WriteRegisterSet() with correct PT_* request
and buffer.
Remove the remaining direct ReadGPR() and WriteGPR() invocations
with ReadRegisterSet() and WriteRegisterSet().
Cleanup suggested by Pavel Labath in D63545.
Differential Revision: https://reviews.llvm.org/D63594
llvm-svn: 363923
That commit changed DIERef from a struct to a class, but did not update
the forward-declarations. This fixes one forward-declaration, and
removes other (unused) decls.
llvm-svn: 363915
Nothing of these tests made much sense. Loops were iterating too much, and I
also don't think it was actually testing anything. I think we simply want to
check that AEK_SOME_EXT returns "+some_ext".
I've given the AArch64 tests the same treatment as they very similarly didn't
made any sense either.
This fixes PR42316.
Differential Revision: https://reviews.llvm.org/D63569
llvm-svn: 363913
Summary:
Instead of accessing the fields directly, use accessor functions to
provide access to the DIERef components. This allows us to decouple the
external interface, from the internal representation. The external
interface can use llvm::Optional and similar goodies, while the data can
still be stored internally in a more compact representation.
I also document the purpose of the existing DIERef fields.
The main motivation for this change is a need to introduce an additional
field to the DIERef class, but I believe the change has its own merit.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63400
llvm-svn: 363910
The original pimpl pattern used between CodegenNameGenerator and
CodegenNameGeneratorImpl did a good job of hiding DataLayout making it so that
users of CodegenNameGenerator did not need to link with llvm core. This is an
NFC change to neatly wrap ASTNameGenerator in a pimpl.
Differential Revision: https://reviews.llvm.org/D63584
llvm-svn: 363908
The caller of this is looking for comparisons of the input
to these instructions with 0. But the memory instructions
input is an addess not a value input in a register.
llvm-svn: 363907
Introducing VCC defs during SIFixSGPRCopies is generally
problematic. Avoid it by starting with the VOP3 form with the general
condition register. This is the easiest to fix instance, but doesn't
solve any specific problems I'm looking at.
llvm-svn: 363904
The ARMDisassembler changes allow changing between ARM and Thumb mode
based on the MCSubtargetInfo, rather than the Target, which simplifies
the other changes a bit.
I'm not really happy with adding more target-specific logic to
tools/llvm-objdump/, but there isn't any easy way around it: the logic
in question specifically applies to disassembling an object file, and
that code simply isn't located in lib/Target, at least at the moment.
Differential Revision: https://reviews.llvm.org/D60927
llvm-svn: 363903
This is incomplete, and ideally these would all be removed, but it's
better to localize them to the subtarget first with comments about
what they're for.
llvm-svn: 363902
Summary:
Stop referring to "numeric expression", using simply the term
"expression" instead. Likewise for numeric operation since operations
are only used in numeric expressions.
Reviewers: jhenderson, jdenny, probinson, arichardson
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63500
llvm-svn: 363901
Summary:
Make use of Error and Expected to bubble up diagnostics and force
checking of errors in the callers.
Reviewers: jhenderson, jdenny, probinson, arichardson
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63125
llvm-svn: 363900
In this mode the tool would avoid duplicating the contents of the
program state on every node, replacing them with a diff-like dump
of changes that happened on that node.
This is useful because most of the time we only interested in whether
the effect of the statement was modeled correctly. A diffed graph would
also be much faster to load and navigate, being much smaller than
the original graph.
The diffs are computed "semantically" as opposed to plain text diffs.
I.e., the diff algorithm is hand-crafted separately for every state trait,
taking the underlying data structures into account. This is especially nice
for Environment because textual diffs would have been terrible.
On the other hand, it requires some boilerplate to implement.
Differential Revision: https://reviews.llvm.org/D62761
llvm-svn: 363898
Quotes around StringRegions are now escaped and unescaped correctly,
producing valid JSON.
Additionally, add a forgotten escape for Store values.
Differential Revision: https://reviews.llvm.org/D63519
llvm-svn: 363897
Include a unique pointer so that it was possible to figure out if it's
the same cluster in different program states. This allows comparing
dumps of different states against each other.
Differential Revision: https://reviews.llvm.org/D63362
llvm-svn: 363896
Location context ID is a property of the location context, not of an item
within it. It's useful to know the id even when there are no items
in the context, eg. for the purposes of figuring out how did contents
of the Environment for the same location context changed across states.
Differential Revision: https://reviews.llvm.org/D62754
llvm-svn: 363895
This changes the checker callback signature to use the modern, easy to
use interface. Additionally, this unblocks future work on allowing
checkers to implement evalCall() for calls that don't correspond to any
call-expression or require additional information that's only available
as part of the CallEvent, such as C++ constructors and destructors.
Differential Revision: https://reviews.llvm.org/D62440
llvm-svn: 363893
Louis Dionne