1234567891011121314151617181920212223242526272829303132333435363738394041424344454647 |
- 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!
- //===---------------------------------------------------------------------===//
|