[LLVMdev] Getelementptr woes

[Chris Lattner]

On Fri, 18 Jun 2004, Vladimir Prus wrote:
> Chris Lattner wrote:
> > Because of this pattern, emitShiftOperation is used by the constant
> > expression support routines (see copyConstantToRegister) to codegen shift
> > constant expressions as well as shift instructions themselves.
>
> But I'd still have to write copyConstantToRegister for my backend, which is
> code duplication. What I'm trying to avoid is making by backend a blatant
> copy-paste.

I realize this.  :)  As you have noticed there are _several_ instances of
code duplication currently required in the instruction selectors.  There
is a mid-term plan to fix this, but it's probably not going to happen for
a couple of months.  If you'd like me to discuss my plans, I can certainly
do so.

If you really want to implement a ConstantExpr lowering pass, I guess
that's ok, and in-line with the other lowering passes we have.  You're
right that the other code generators in progress would benefit from it as
well.

> > I don't think this is TOO completely horrible to support constant
> > expressions in general, though it can (and will be in the future)
> > certainly be improved.
>
> Ok, I've another idea. I wonder if it's possible to create
> 'BasicInstructionSelector'. It would have a bunch of pure virtual methods
> like emitShiftOperation and
> 1. Visitors for each operations, written just like above
> 2. Handling for constant expressions.
>
> So, individual backend would have to implement only emitShiftOperation and
> other emit* methods.

Hrm, there is a flaw in your logic: you're assuming that the current form
of instruction selection is basically the right one and just needs to be
cleaned up.  Unfortunately that is not the case.  In the medium term we
want to move to an optimal pattern matching instruction selector and a
more structured lowering mechanism.

What we *want* is for the *instrinfo.td files to contain a code pattern
for each instruction and have the instruction selector autogenerated from
that.  The idea is to make instruction selection just like the rest of the
back end: the user describes the *target*, not hooks for a particular
algorithm to call into.

If you're interested in working on the longer term stuff, please let me
know.  This is clearly the right direction to go to, but we are a way from
it.  OTOH, if you'd like to work on a "basic instruction selector" with
callbacks, that is also cool, but it may be obsoleted in a few months.

> > > The second pass would convert getelementptr into casts and pointer
> > > arithmetic.
> > To expand out a getelementptr into code it basically just walks through
> > the indices turning them into the appropriate scale and add as
> > appropriate.  It's quite a bit simpler and cleaner to just implement
> > support for this instead of hacking it into casts and pointer arithmetic.
> >
> > :)
>
> Uhm... the code runs from line 2311 till line 2433 so I naturally don't want
> to copy-paste it ;-) And the only target-specific parts are instruction
> codes. There should be some way to abstract this.... gotta try further.

Yes I agree.  See above.  :)

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/