[llvm-commits] DAGCombiner Patch: Allow targets to do combine first.

[Dan Gohman]

On Mar 24, 2009, at 3:17 AM, Sanjiv.Gupta at microchip.com wrote:

> The DAGCombiner::combine() in its existing form does not allow  
> targets to do anything if the visitNODE() has done something with it.
> IMO, the targets should always be allowed to do stuff irrespective  
> of what we want to do in visitNODE().

DAGCombine is iterative; I believe the target hook will be called
after DAGCombine is done hacking with it. I guess what your patch does
is add a hook to let the target intervene before DAGCombine runs. One
of the main purposes of the first DAGCombine runs is to clean up and
canonicalize the mess that SelectionDAGLowering emits so that the rest
of CodeGen doesn't have to deal with it. Consequently, it's not clear
why it would be useful to give targets a hook to step into the mess,
in general. And in the specific case that's motivating this, it seems
that trying to fix this problem by selectively disabling optimizations
seems to be swimming upstream.

> Attached is a patch for same. Let me know if it sounds ok. I will go  
> ahead and commit it.

Please send normal attachments. winmail.dat seems to be some
Outlook-specific thing.

LLVM's CodeGen is designed for register architectures. When it
is used to target stack architectures, the preferred approach
seems to be to do instruction selection as if the target had
registers and instructions that operate on registers, and then
to lower everything to stack operations in a later phase. PIC16
seems to be an accumulator architecture. Would it make sense
to take a similar approach?

Ultimately, LLVM does have its share of hacks for expedience,
so this probably won't be forbidden, if that's the case.

Dan