[LLVMdev] InstCombine Question
David Greene
dag at cray.com
Fri Apr 4 13:01:24 PDT 2008
On Friday 04 April 2008 13:42, David Greene wrote:
> On Friday 04 April 2008 13:07, Chris Lattner wrote:
> > > So how does the undef store to null appear in the IR when it isn't
> > > attached anywhere and how can I get rid of it?
> >
> > Don't do undefined behavior? :)
>
> I don't think it's undefined behavior. Right before instcombine, we have
> this:
>
> %r60 = load <2 x i64>* %"$LCS_1", align 16 ; <<2 x i64>> [#uses=2] ;
> srcLine 41
> %r61 = extractelement <2 x i64> %r60, i32 0 ; <i64> [#uses=1] ; srcLine
> 41 %r62 = getelementptr <2 x double>* null, i32 0, i64 %r61 ; <double*>
> [#uses=1] ; srcLine 41
> %r63 = load double* %r62 ; <double> [#uses=1] ; srcLine 41
>
> So we're loading a vector of pointers and then using getelementptr as
> basically a reg-reg copy with a cast (I think). Yes, it's a little weird,
> but legal AFAICS.
>
> I'm not sure if the above code is really kosher. It is very strange to see
> the typing of the extractelement and GEP here.
Actually, there are multiple problems. The first zero index on the GEP is
wrong. I believe that it should be the following:
%r62 = getelementptr <2 x double>* null, i64 %r61
This is essentially the equivalent of a bitcast, then.
The second problem is the typing of the GEP and the following load.
Clearly that's wrong. The GEP should return a double *.
These are problems in our compiler, not LLVM. But I do want to ask
about the legality of the revised GEP above. Is that legal code? If so,
instcombine should not be removing it as dead code.
-Dave
More information about the llvm-dev
mailing list