llvm dev - Dec 2011 - [LLVMdev] How to make Polly ignore some non-affine memory accesses

2011/11/21 Tobias Grosser <tobias at grosser.es>:
> On 11/20/2011 04:36 PM, Marcello Maggioni wrote:
>>
>> Sorry for the noobish question, but what kind of subscripts generate a
>> SCEVCouldNotCompute  from the SCEV engine?
>> I tried for a while but I wasn't able to trigger that
>
> Hi Marcello,
>
> the SCEV returns SCEVCouldNotCompute in case it cannot analyze an
expression
> or if the analysis would be to complicated. I am currently
> not sure if this may actually happen when calling getSCEV(), because
> getSCEV() could just return a SCEVUnknown referencing the Value itself.
> Maybe SCEVCouldNotCompute is just generated by functions like
> SE->getBackedgeTakenCount()?
>
> In case you cannot generate a test case that yields to this, I don't
think
> there is a need to try more. Even without such a test case the patch should
> be OK.
>
> Cheers
> Tobi
>
Ok, thanks, I'll try other test cases to check if everything is ok,
better being sure.

About SCOPs with a "bitcast instruction" inside them I see that
ScopDetection discards those.
What problems can cause bitcasts to the Scop? Is it related to aliasing?

Marcello

On 11/21/2011 03:44 AM, Marcello Maggioni wrote:
> 2011/11/21 Tobias Grosser<tobias at grosser.es>:
>> On 11/20/2011 04:36 PM, Marcello Maggioni wrote:
>>>
>>> Sorry for the noobish question, but what kind of subscripts
generate a
>>> SCEVCouldNotCompute  from the SCEV engine?
>>> I tried for a while but I wasn't able to trigger that
>>
>> Hi Marcello,
>>
>> the SCEV returns SCEVCouldNotCompute in case it cannot analyze an
expression
>> or if the analysis would be to complicated. I am currently
>> not sure if this may actually happen when calling getSCEV(), because
>> getSCEV() could just return a SCEVUnknown referencing the Value itself.
>> Maybe SCEVCouldNotCompute is just generated by functions like
>> SE->getBackedgeTakenCount()?
>>
>> In case you cannot generate a test case that yields to this, I
don't think
>> there is a need to try more. Even without such a test case the patch
should
>> be OK.
>>
>> Cheers
>> Tobi
>>
>
> Ok, thanks, I'll try other test cases to check if everything is ok,
> better being sure.
>
> About SCOPs with a "bitcast instruction" inside them I see that
> ScopDetection discards those.
> What problems can cause bitcasts to the Scop? Is it related to aliasing?
I don't know. At the moment I wrote the scop detection I was not sure 
that they don't cause any problems, so I conservatively discarded them.
Meanwhile I actually believe the don't introduce any problems and could 
be allowed. However, before changing this, I would like to set up a 
nightly tester that ensures the llvm test suite is compiled correctly.
This would allow us to understand if the support for this construct 
introduces any regressions.

Cheers
Tobi

On 11/21/2011 12:44 PM, Marcello Maggioni wrote:
> 2011/11/21 Tobias Grosser<tobias at grosser.es>:
>> On 11/20/2011 04:36 PM, Marcello Maggioni wrote:
>>>
>>> Sorry for the noobish question, but what kind of subscripts
generate a
>>> SCEVCouldNotCompute  from the SCEV engine?
>>> I tried for a while but I wasn't able to trigger that
>>
>> Hi Marcello,
>>
>> the SCEV returns SCEVCouldNotCompute in case it cannot analyze an
expression
>> or if the analysis would be to complicated. I am currently
>> not sure if this may actually happen when calling getSCEV(), because
>> getSCEV() could just return a SCEVUnknown referencing the Value itself.
>> Maybe SCEVCouldNotCompute is just generated by functions like
>> SE->getBackedgeTakenCount()?
>>
>> In case you cannot generate a test case that yields to this, I
don't think
>> there is a need to try more. Even without such a test case the patch
should
>> be OK.
>>
>> Cheers
>> Tobi
>>
>
> Ok, thanks, I'll try other test cases to check if everything is ok,
> better being sure.
Hi Marcello,

any news here? I would love to commit your patch. Do you happen to have 
a final version ready?

Cheers
Tobi

Hi, sorry for the late response. I've been away for a week and after
that probably I missed your email (considering the high amount of
mails that come from LLVMDev :p )
Anyway, now it's just a matter of checking the code , I'm finalizing a
test and after that (a couple of days) I'll post the patch hoping
everything is ok :)

Thank you

Marcello

2011/12/4 Tobias Grosser <tobias at grosser.es>:
> On 11/21/2011 12:44 PM, Marcello Maggioni wrote:
>>
>> 2011/11/21 Tobias Grosser<tobias at grosser.es>:
>>>
>>> On 11/20/2011 04:36 PM, Marcello Maggioni wrote:
>>>>
>>>>
>>>> Sorry for the noobish question, but what kind of subscripts
generate a
>>>> SCEVCouldNotCompute  from the SCEV engine?
>>>> I tried for a while but I wasn't able to trigger that
>>>
>>>
>>> Hi Marcello,
>>>
>>> the SCEV returns SCEVCouldNotCompute in case it cannot analyze an
>>> expression
>>> or if the analysis would be to complicated. I am currently
>>> not sure if this may actually happen when calling getSCEV(),
because
>>> getSCEV() could just return a SCEVUnknown referencing the Value
itself.
>>> Maybe SCEVCouldNotCompute is just generated by functions like
>>> SE->getBackedgeTakenCount()?
>>>
>>> In case you cannot generate a test case that yields to this, I
don't
>>> think
>>> there is a need to try more. Even without such a test case the
patch
>>> should
>>> be OK.
>>>
>>> Cheers
>>> Tobi
>>>
>>
>> Ok, thanks, I'll try other test cases to check if everything is ok,
>> better being sure.
>
>
> Hi Marcello,
>
> any news here? I would love to commit your patch. Do you happen to have a
> final version ready?
>
> Cheers
> Tobi
>

Perfect! :)
Thank you for all the help!

Marcello

2011/12/20 Tobias Grosser <tobias at grosser.es>:
> On 12/19/2011 05:45 PM, Marcello Maggioni wrote:
>>
>> Hi, here the latest version of the patch.
>>
>> Sorry for the wait :)
>
>
> Thanks a lot. The patch looked good. I added some last style changes, but
> nothing big (80 columns violation and adding an early exit).
>
> I pushed the change out to Polly.
>
> Cheers
> Tobi