Mercurial > hg > CbC > CbC_llvm
comparison clang/lib/CodeGen/README.txt @ 150:1d019706d866
LLVM10
| author | anatofuz |
|---|---|
| date | Thu, 13 Feb 2020 15:10:13 +0900 |
| parents | |
| children |
comparison
equal
deleted
inserted
replaced
| 147:c2174574ed3a | 150:1d019706d866 |
|---|---|
| 1 IRgen optimization opportunities. | |
| 2 | |
| 3 //===---------------------------------------------------------------------===// | |
| 4 | |
| 5 The common pattern of | |
| 6 -- | |
| 7 short x; // or char, etc | |
| 8 (x == 10) | |
| 9 -- | |
| 10 generates an zext/sext of x which can easily be avoided. | |
| 11 | |
| 12 //===---------------------------------------------------------------------===// | |
| 13 | |
| 14 Bitfields accesses can be shifted to simplify masking and sign | |
| 15 extension. For example, if the bitfield width is 8 and it is | |
| 16 appropriately aligned then is is a lot shorter to just load the char | |
| 17 directly. | |
| 18 | |
| 19 //===---------------------------------------------------------------------===// | |
| 20 | |
| 21 It may be worth avoiding creation of alloca's for formal arguments | |
| 22 for the common situation where the argument is never written to or has | |
| 23 its address taken. The idea would be to begin generating code by using | |
| 24 the argument directly and if its address is taken or it is stored to | |
| 25 then generate the alloca and patch up the existing code. | |
| 26 | |
| 27 In theory, the same optimization could be a win for block local | |
| 28 variables as long as the declaration dominates all statements in the | |
| 29 block. | |
| 30 | |
| 31 NOTE: The main case we care about this for is for -O0 -g compile time | |
| 32 performance, and in that scenario we will need to emit the alloca | |
| 33 anyway currently to emit proper debug info. So this is blocked by | |
| 34 being able to emit debug information which refers to an LLVM | |
| 35 temporary, not an alloca. | |
| 36 | |
| 37 //===---------------------------------------------------------------------===// | |
| 38 | |
| 39 We should try and avoid generating basic blocks which only contain | |
| 40 jumps. At -O0, this penalizes us all the way from IRgen (malloc & | |
| 41 instruction overhead), all the way down through code generation and | |
| 42 assembly time. | |
| 43 | |
| 44 On 176.gcc:expr.ll, it looks like over 12% of basic blocks are just | |
| 45 direct branches! | |
| 46 | |
| 47 //===---------------------------------------------------------------------===// |