> Am 18.09.2022 um 11:10 schrieb Mikael Morin <morin-mik...@orange.fr>:
>
> Le 18/09/2022 à 08:12, Richard Biener a écrit :
>>> On Sat, Sep 17, 2022 at 9:33 PM Mikael Morin <morin-mik...@orange.fr> wrote:
>>>
>>> Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
>>>>
>>>> I have a concern about this part, though. My understanding at the
>>>> time was that it is not possible to clobber an individual array
>>>> element, but that this clobbers anything off the pointer that this
>>>> is based on.
>>>>
>>> Well, we need the middle-end guys to give a definitive answer on this
>>> topic, but I think it would be a very penalizing limitation if that was
>>> the case. I have assumed that the clobber spanned the value it was
>>> applied on, neither more nor less, so just the array element in case of
>>> array elements.
>> There is IL verification that the LHS of a CLOBBER is either
>> a declaration or a pointer dereference, no array or component
>> selection is allowed there. Now, nothing should go wrong here,
>> but we might eventually just drop those CLOBBERs or ICE if
>> we frontend hands us an "invalid" one.
>
> Obviously I have assumed too much here; it's probably best to drop this patch.
> It is unfortunate as there is some desirable behavior within reach here. The
> test shows that the patch permits the elimination of a useless store. And IL
> verification doesn't seem that upset with it by the way.
> Does *(&a[1]) count as a pointer dereference?
Yes, technically.
> Even in the original dump it is already simplified to a straight a[1].
But this not anymore. The check can probably be relaxed, it stems from the
dual purpose of CLOBBER.
Richard
