This commit fixes a TypeShrinking bug and extends it to better handle
more instructions. Specifically, we now handle shift left, select, phi
and bitwise operations.
This commit introduces a change in AdvancedValueInfoMFI which forces to
consider constraints valid on 32-bit values to be valid on their
untruncated 64-bit counterparts.
While being unsound, this is important to easily devirtualize indirect
branches on 64-bit architectures where often constraints are expressed
on 32-bit switch values.
This analysis will be used for the following features:
1) Edit Type in the Model
2) Edit Function Prototype in the Model
3) Add Type to the Model
It takes C code as an input, parses it and produces a Model
type that represents the C type.
Before this commit initModelTypes wasn't able to detect the type of the
callee operand for calls to isolated functions.
This commit properly supports this case.
Before this commit, we were blinding adding the `nomerge` attribute to
function calls. Now we copy attributes over, so we preserve all the
attributes.
In this way the only place where we add the `nomerge` attribute becomes
Isolate.
The goal of this update is to propagate prototypes of functions called
in wrappers to this wrappers.
When some function hasn't it's own prototype, but the only thing it does
is calling another function, DetectABI pass sets callee prototype as
caller prototype also.
This behaviour is limited to callers that:
1. have only one basic block
2. end with call
3. don't write arguments of callee
4. don't modify stack pointer
5. don't write to memory.
Before this commit, we were only copying the metadata attached to the
CallInst, but we need to copy also the attributes, otherwise we might
lose important information, such as `nomerge`.
Not every case can benefit from extra liniency, so they were manually
reviewed on a case by case basis.
Additionally, this drops a couple of "this should be a non-strict
specialization" commits, because of a bug with clang
(see the GenericGraph concepts rework commit for more details) as
to avoid confusion (we wouldn't want anyone trying to solve these
"todo"s) until the clang struct type deduction is fixed. Especially
considering that there are currently no cases where these softer
versions would be beneficial (we never inherit from templates in
question).
Alessandro Di Federico