This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Functions that are CSEable but not pure

On Thu, Oct 4, 2012 at 2:56 PM, Jason Merrill <> wrote:
> On 10/04/2012 08:45 AM, Jakub Jelinek wrote:
>> On Thu, Oct 04, 2012 at 10:42:59AM +0200, Richard Guenther wrote:
>>> On Wed, Oct 3, 2012 at 9:00 PM, Jason Merrill <> wrote:
>>> If the result is not needed, are we allowed to remove a call to this
>>> function?
>> No.  Unless you know the same function has been already called.
> Yes, we are.  If we optimize away a use of the variable, we can also remove
> the call to the function.  We can also hoist the call so its side-effects
> occur before other side-effects, as the standard only requires that the
> initialization of the variable occur some time between thread creation and
> the first use of the variable.
>>> So - what's wrong with using pure?  That it doesn't "feel" correct?
>> No, it can modify memory.
> Right, that's the issue.  The back end assumes that calls to pure functions
> won't clobber memory; calls to these functions can clobber arbitrary memory,
> but only on the first call.

Ugh.  Especially with the above (you can DCE those calls) makes this
severly mis-specified ... and any implementation error-prone (look what
mess our losely defined 'malloc' attribute opened ...).

I thought of a testcase like

 int *p = get_me ();
 .. = *p;
 int *q = get_me ();
 .. = *q;

and get_me allocating/initalizing and returning a singleton.

But you tell me it's more complicated and get_me () needs to
be a barrier for any load/store (as it may modify arbitrary memory,
but only on the "first" call).

I think that "may modify arbitrary memory" isn't going to fly and
my answer would be, better don't try to optimize anything here,
at least not in generic terms.  How would you handle this in
the alias oracle?  How would you then make CSE recognize
two functions return the same value and are CSEable?

>> I think the plan was for these functions not to return any value,
> No, I'm talking about the wrapper function which returns a reference to the
> variable (as in my example).

Can you come up with a short but complete testcase illustrating the issue
better (preferably C, so I don't need to read-in magic points where construction


> Jason

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]