48 lines
		
	
	
		
			1.8 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			48 lines
		
	
	
		
			1.8 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| 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!
 | |
| 
 | |
| //===---------------------------------------------------------------------===//
 | 
