[LLVMdev] Making optimization passes do less

[Matthijs Kooijman]

Hi all,

I'm currently struggling with a few optimization passes that change stuff I
don't want to be changed. However, for the most part those passes (InstructionCombining
and SimplifyCFG currently) do stuff that I do want, so disabling them
alltogether doesn't help me much.

The problem arises because the architecture I'm compiling for is quite
non-standard. In particular, it has the ability to execute a lot of
instructions in parallel, but at the same time can't execute everything you
throw at it.

My problem with SimplifyCFG is the following: Whenever the if and else branch
start with the same instruction, it gets hoisted up into the predecessor
block. For my architecture, instructions in different blocks can't be run in
parallel, so this optimization makes code either very inefficient or not
compile at all.

InstructionCombining has this habit of removing unneeded bits from constants.
For example, if I do i & 63, where i is a loop counter that is always even,
this gets replaced by i & 62. Which gives, of course, the same results when
interpreted, but our backend cannot just use any constant as an & mask (in
particular, it can only use a limited amount of them). I'd very much prefer to
preserve the original value from the source here (I also assume that this
optimization is in place to help further optimizations, because I can't really
see any use of this change on regular architectures...).

I've been thinking a bit on how to achieve this, and I see a few options:
 * Use a local patch to simply disable the parts of the passes we don't want,
	 optionally protected by some check to only disable it when it's unwanted.
	 This would be a very effective approach, though also very much unwanted.
	 Local patches to the LLVM source are a pain to maintain.
 * Use some kind of subclassed pass. Since, AFAICS, simply subclassing an
	 existing pass doesn't really work due to the class ID stuff, this requires
	 making a superclass to do most of the work and a subclass to decide when to
	 do it in LLVM, so we can add another subclass (similar to the Inliner
	 pass). Alternatively, the functionality of instruction combining could be
	 split off into a utility class, though that would prevent using overriding
	 methods to disable some functionality. This approach could be useful, but
	 I can't really see how it would work out yet.
 * Add options to the current passes. I could add an option to the current
   passes to make them do what I want (either using an option to
	 createXXXPass() and the constructor, or perhaps using a set_XXX_option()
	 methode or something). This might work for SimplifyCFG, since that option
	 could be made a bit more generic, such as "Don't move instructions between
	 blocks" (leaving SimplifyCFG free to merge blocks whenever appropriate).

	 For InstructionCombining this is harder, since our requirements are not as
	 easily captured in an elegant option, I'm afraid.
 * Mark instructions / values as immutable. We could write a pass that marks
   the values we want preserved as immutable and other passes should leave
	 those values alone. This requires quite some modification to LLVM (probably
	 even the IR) and all optimization passes. Though I think it's actually
	 quite an elegant solution, it's probably hard to express everything we need
	 in it (also, if we mark some instruction or value as immutable, it's hard
	 to prevent a pass from making a copy of the instruction (perhaps
	 indirectly) and simply making the immutable instruction unused).
 * Use some kind of TargetInfo/TargetData struct to control certain
   optimizations. I'm not really sure how this is used now, but I could
	 imagine that there is some interface for optimization passes to find out
	 what optimizations are worthwile and what are not (something like a
	 bool isBetter(Value* old, Value* new) as a very simple example. Is there
	 already something like this?
	
None of these options seem too attractive to me, what do others think? Is
there some other option I'm missing here?

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080526/c5ab4241/attachment.sig>