This reworks NameBuilder to ease the transition to the system where
the model will be guaranteed to never contain any name collisions, both
between user-specified names and the automatic ones.
This commit further centralizes the creation of allocas + ptrtoint. The
creation of these pair of instructions is problematic when the size of a
pointer in the input and target architecture differ.
In fact, in such cases, LLVM turns trunc into masking the integer to
suppresse the high bits. This results in problematic code.
This commit introduces an assumption that ensures LLVM does not do that.
This commit adopts `PatternMatch.h` and adds support discarding
alignment operations even if they are performed after manipulating the
stack pointer.
For instance, glibc's `_start` does the following:
xor ebp,ebp
mov r9,rdx
pop rsi
mov rdx,rsp
and rsp,0xfffffffffffffff0
Introduce LegacySegregateStackAccessesPipe
This commit restructures the SegregateStackAccesses pass and
SegregateStackAccessesPipe so that they can have 2 modes of operations:
1. Legacy, with the same behavior as the old version, injecting local
variables as custom llvm::Functions representing opcodes, such as
LocalVariable, AddressOf, StackFrameAllocator, and CallStackArguments
allocator.
2. Non-legacy, that is meant to operate with the new LocalVariableHelper
to inject local variables as regular alloca instructions, with
additional metadata to discriminate among them.
This commit renames the old SegregateStackAccessesPipe to
LegacySegregateStackAccessesPipe.
It then re-uses the old SegregateStackAccessesPipe name for a new pipe,
meant to work in non-legacy mode.
The pipeline definition YAML file is updated to keep using the legacy
version for now.
For now the implementation is still the same.
This is preliminary to unifying the creation and handling of local
variable declarations, to simplify switching over to local variables
represented by plain allocas.
Before this commit, the code was making a couple of broken assumptions on
OpaqueExtractValues
- that OpaqueExtractValues were always ordered in the same way as struct
fields (e.g. the OpaqueExtractValue extracting field 0 was always the
first use of the struct-typed value it was extracting from)
- that there was always one and exactly one OpaqueExtractValue for each
field index in the struct
This commit fixes the issue, while reusing available facilities for
dealing with OpaqueExtractValues.
This commit heavily reworks how we handle returned values, making things
a bit more elegant.
Apart from this, it fixes how were handling types that on the model are
aggregates but were being returned via registers on the IR.
Ivan Krysak