You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
48 lines
1.8 KiB
48 lines
1.8 KiB
4 months ago
|
IRgen optimization opportunities.
|
||
|
|
||
|
//===---------------------------------------------------------------------===//
|
||
|
|
||
|
The common pattern of
|
||
|
--
|
||
|
short x; // or char, etc
|
||
|
(x == 10)
|
||
|
--
|
||
|
generates an zext/sext of x which can easily be avoided.
|
||
|
|
||
|
//===---------------------------------------------------------------------===//
|
||
|
|
||
|
Bitfields accesses can be shifted to simplify masking and sign
|
||
|
extension. For example, if the bitfield width is 8 and it is
|
||
|
appropriately aligned then is is a lot shorter to just load the char
|
||
|
directly.
|
||
|
|
||
|
//===---------------------------------------------------------------------===//
|
||
|
|
||
|
It may be worth avoiding creation of alloca's for formal arguments
|
||
|
for the common situation where the argument is never written to or has
|
||
|
its address taken. The idea would be to begin generating code by using
|
||
|
the argument directly and if its address is taken or it is stored to
|
||
|
then generate the alloca and patch up the existing code.
|
||
|
|
||
|
In theory, the same optimization could be a win for block local
|
||
|
variables as long as the declaration dominates all statements in the
|
||
|
block.
|
||
|
|
||
|
NOTE: The main case we care about this for is for -O0 -g compile time
|
||
|
performance, and in that scenario we will need to emit the alloca
|
||
|
anyway currently to emit proper debug info. So this is blocked by
|
||
|
being able to emit debug information which refers to an LLVM
|
||
|
temporary, not an alloca.
|
||
|
|
||
|
//===---------------------------------------------------------------------===//
|
||
|
|
||
|
We should try and avoid generating basic blocks which only contain
|
||
|
jumps. At -O0, this penalizes us all the way from IRgen (malloc &
|
||
|
instruction overhead), all the way down through code generation and
|
||
|
assembly time.
|
||
|
|
||
|
On 176.gcc:expr.ll, it looks like over 12% of basic blocks are just
|
||
|
direct branches!
|
||
|
|
||
|
//===---------------------------------------------------------------------===//
|