Re: [PATCH] Implement malloc/free hoisting from loops (PR21046 and friends)

[Richard Guenther <richard dot guenther at gmail dot com>]

On Fri, May 14, 2010 at 6:22 AM, Xinliang David Li <davidxl@google.com> wrote:
> On Thu, May 13, 2010 at 4:17 PM, Mark Mitchell <mark@codesourcery.com> wrote:
>> Xinliang David Li wrote:
>>
>>>> ?In general,
>>>> when you call a standard function, GCC may either (a) generate inline
>>>> code, (b) call that function, or (c) call some other function.
>>>
>>> Or combination of those transformation, or making assumption in
>>> aliasing/moduse analysis etc on those.
>>
>> Indeed.
>>
>>>> ?(An
>>>> example of (c) is replacing a call to "printf" with a constant string
>>>> with a call to "puts".)
>>>>
>>> These are the ones like stringops which are 'immune' to implementation
>>> details. Again it would be helpful if things like pragma builtin or
>>> attribute(builtin) are thrown in the header.
>>
>> I don't think "printf" is in the same category as "strcmp". ?I've
>> basically never seen a strcmp with side-effects, but there are lots of
>> printf implementations out there with differing behavior. ?I do agree
>> that "malloc" is pretty far up the continuum, though.
>>
>> Putting attributes in a header isn't really the right thing; the issue
>> you're raising is about the implementation. ?I think you'd have to do a
>> (dynamic, in some cases) link-time check. ?(For example, on a GLIBC
>> system, I can replace "malloc" in my application -- the header isn't the
>> issue.)
>>
>> In the short term, I don't see any alternatives beyond the one we
>> already have: command-line options to tell the compiler that it must not
>> make assumptions about certain functions.
>
> In practice, current way of handling should work just fine. It is just
> a little weird for user to implicitly assert library function
> behaviors (set as default by the compiler) instead of being asserted
> by the library writer.

For the library writer we have attributes plus we rely on effects and
side-effects as documented by the relevant standards.  For the
user replacing library functionality we have to rely on optimization
switches.

I wouldn't be totally against something alongside -funsafe-math-optimizations
for non-math code - like -fno-preserve-side-effects (with
-fpreserve-side-effects being the default).  This would for example
allow us to even remove pairs of malloc/free calls that are unused,
removing the side-effect of eventually setting errno.

Richard.