diff options
Diffstat (limited to 'clang/lib/CodeGen/README.txt')
-rw-r--r-- | clang/lib/CodeGen/README.txt | 47 |
1 files changed, 47 insertions, 0 deletions
diff --git a/clang/lib/CodeGen/README.txt b/clang/lib/CodeGen/README.txt new file mode 100644 index 0000000..e6d6109 --- /dev/null +++ b/clang/lib/CodeGen/README.txt @@ -0,0 +1,47 @@ +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! + +//===---------------------------------------------------------------------===// |