On Fri Sep 18, 2026 at 12:12 PM CEST, Jakub Jelinek wrote:
> On Thu, Sep 10, 2026 at 04:58:45PM +0200, Josef Melcr wrote:
>> this patch changes IFN_ASSUME to be pure instead of const.  The const
>> attribute means (not only) that the function cannot read global memory.
>> While this is true for the internal call itself, it is only a dispatcher
>> for the outlined assume body, which may read any memory, e.g. below:
>> 
>> ```
>> struct S
>> {
>>   int x, y;
>> };
>> 
>> void bar (int, int);
>> 
>> bool
>> foo (struct S *s)
>> {
>>   [[assume (bar (s->x, s->y))]];
>
> This is not valid, assume expression is contextually converted to bool,
> you can't convert void to bool.  So just make it bool bar (int, int);
> in the commit log.

Oops, typo :)  Will be fixed in the commit log of course.

>
>>   return s->x;
>> }
>> ```
>> 
>> Now, the read does not actually happen in reality, as the assume's body
>> does not make into the final binary, but the call being marked
>> incorrectly as const makes our analysis less accurate.
>
> The outlined assume body may also store memory, but as it is never actually
> called (all the side-effects are as-if), I think your patch is ok.
> It will make some GIMPLE DSE etc. decisions worse (e.g. any escaped memory
> won't be possible to be DSEd if there is some IFN_ASSUME after it), but
> hopefully when the IFN_ASSUME call is optimized out we'll be able to still
> DSE it afterwards.

That's the idea.  I think that DSE is currently too active around
assumes, I want the stores eliminated in RTL, if they aren't made
redundant earlier by some other pass.

> We could also analyze the corresponding outlined function and if it doesn't
> read any memory, make a particular IFN_ASSUME call const or novops.

I had that idea as well, I think it's viable.  A possible improvement
once the IPA for assumes patches are in?

Just to sure, this is OK to commit (with the typo fixed)?

>
>>      PR ipa/127104
>> 
>> gcc/ChangeLog:
>> 
>>      * internal-fn.def (ASSUME): Downgrade from const to pure.
>> 
>> Signed-off-by: Josef Melcr <[email protected]>
>
>       Jakub

Best regads,
Josef

Reply via email to