[LLVMdev] llvm::ConvertibleToGEP

[Chris Lattner]

On Tue, 26 Jul 2005, Naftali Schwartz wrote:

> Well, I guess I was hoping soemthing like this would help in the 
> pointer-to-array transformation for the following code:
>
>> > int A[100], B[100], C[100], X, Y, Z;
>> >
>> >        int *p_a = &A[0];
>> >        int *p_b = &B[0];
>> >        int *p_c = &C[0];
>> >
>> >        int i, j, k, f;
>> >        for ( k = 0; k < Z; k++ )
>> >        {
>> >                p_a = &A[0];
>> >                for ( i = 0; i < X; i++ )
>> >                {
>> >                        p_b = &B[k*Y];
>> >                        *p_c = *p_a++ * *p_b++;
>> >                        for ( f = 0; f < Y-2; f++ )
>> >                                *p_c += *p_a++ * *p_b++;
>> >                        *p_c++ += *p_a++ * *p_b++;
>> >                }
>> >        }
>
> which, as you had pointed out, removal of the if statement in 
> IndVarSimplify:647 takes care of, but only partially, as it leaves the p_a 
> and p_c references exactly as before.  On the other hand, maybe I'm just a 
> little confused...

No, I don't think the ConvertibleToGEP idea would help you here.  If you 
notice this part:

         int *p_a = &A[0];

... for example, it is not doing the cast that ConvertibleToGEP would 
unravel.  In particular, the ConvertibleToGEP thing would fix a case like 
this:

         int *p_a = (int*)A;

turning it into the address of/subscript pair (which is just a 
getelementptr instruction).

-Chris

> Naftali
>
> On Tue, 26 Jul 2005, Chris Lattner wrote:
>
>> On Tue, 26 Jul 2005, Naftali Schwartz wrote:
>>> I'm sorry, it had seemed to me that the documented functionality:
>>> 
>>> // ConvertibleToGEP - This function returns true if the specified value V 
>>> is
>>> // a valid index into a pointer of type Ty.  If it is valid, Idx is filled 
>>> in
>>> // with the values that would be appropriate to make this a getelementptr
>>> // instruction.  The type returned is the root type that the GEP would 
>>> point to
>>> 
>>> would be quite useful (and in particular for dependence analysis).
>>> Are you going to remove it because it's functionality is already present 
>>> elsewhere or is simply not needed anymore?
>> 
>> I'm not sure I follow how it is useful for dep analysis.  The -instcombine 
>> pass already does this transformation in a more general way.  In 
>> particular, this code was used to change code like this:
>> 
>> int* %foo({int, float}* %P) {
>>  %Y = cast {int, float}* %P to int*
>>  ret int* %Y
>> }
>> 
>> into:
>> 
>> int* %foo({int, float}* %P) {
>>  %Y = getelementptr {int, float}* %P, int 0, uint 0
>>  ret int* %Y
>> }
>> 
>> In your depedence analyzer, you shouldn't worry about cases like this: 
>> instead, just assume that the optimizer has already cleaned them up for 
>> you.
>> 
>> -Chris
>> 
>> 
>>> On Tue, 26 Jul 2005, Chris Lattner wrote:
>>> 
>>>> On Tue, 26 Jul 2005, Naftali Schwartz wrote:
>>>>> But it's completely empty, no?
>>>>> 
>>>>> const Type *llvm::ConvertibleToGEP(const Type *Ty, Value *OffsetVal,
>>>>>                                   std::vector<Value*> &Indices,
>>>>>                                   const TargetData &TD,
>>>>>                                   BasicBlock::iterator *BI) {
>>>>>  return 0;
>>>>> }
>>>>> 
>>>>> in lib/Transforms/TransformInternals.cpp, how can this be?
>>>> 
>>>> Huh, interesting.  I'll remove it, thanks for pointing it out!
>>>> 
>>>> -Chris
>>>> 
>>>>> On Tue, 26 Jul 2005, Chris Lattner wrote:
>>>>> 
>>>>>> On Tue, 26 Jul 2005, Naftali Schwartz wrote:
>>>>>>> It seems like general dependence analysis in LLVM should require that 
>>>>>>> this function be, well, functional.  Is it simply a placeholder 
>>>>>>> waiting for someone to come and fill in the details?  It also appears 
>>>>>>> that some other things besides dependence analysis depend on it as 
>>>>>>> well...anyone working on this?
>>>>>> 
>>>>>> I don't understand what you mean.  This function is just a little 
>>>>>> utility function used by the "-raise" pass.
>>>>>> 
>>>>>> -Chris
>>>>>> 
>>>>>> -- 
>>>>>> http://nondot.org/sabre/
>>>>>> http://llvm.org/
>>>>>> 
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>> 
>>>> 
>>>> -Chris
>>>> 
>>>> -- 
>>>> http://nondot.org/sabre/
>>>> http://llvm.org/
>>>> 
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>> 
>> 
>> -Chris
>> 
>> -- 
>> http://nondot.org/sabre/
>> http://llvm.org/
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> 
>> 
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/