On Sat, 2 Nov 2024, Alexander Monakov wrote:
>
> On Sat, 2 Nov 2024, Sam James wrote:
>
> > Some references to feed discussion which I had in my logs from
> > discussing it with someone the other week after that interaction we
> > had with alanc:
> > * https://github.com/llvm/llvm-project/issues/28790 (not very
> > insightful, other than to show it has a history of confusing people, but
> > one might argue that for other (definitely-valid) optimisations)
> > * https://github.com/llvm/llvm-project/issues/49826
> > * https://github.com/llvm/llvm-project/issues/51476
>
> Thank you.
>
> I believe in this situation the onus is on us to prove that such transforms
> are correct.
>
> Exhibit A:
>
> POSIX semantics for malloc involve errno.
I'll note there's the open PR that -fno-math-errno makes us assume
malloc doesn't set errno (it helps alias analysis).
> Exhibit B:
>
> malloc is supposed to give unique pointers (without any intervening free's).
> However, the proposed patch should be powerful enough to transform
>
> void f()
> {
> void *p = __builtin_malloc(1);
> if (p) {
> asm("");
> f();
> }
> __builtin_free(p);
> }
>
> to an infinite loop, but infinite amout of unique pointers is impossible.
Heh. I think the f() call will keep the controlling predicate live
though so the optimization will break in this case.
> In a similar vein, five mallocs, each allocating a quarter of address space,
> also seems impossible.
>
> I am reminded that we take a pretty strict stance against enabling
> -fno-math-errno -fno-trapping-math, even though they gate a lot of useful
> vectorization. So it's a bit weird we're going so gung-ho with this malloc
> elimination.
I do hope we re-consider on -fno-trapping-math (given -fno-rounding-math).
I also hope we can add a "no-errno" function attribute so lib[cm] can
decorate their declarations to indicate whether they chose to set errno
or not ... maybe even have a "no-errno(alias)" so you can have
double sin(double) __attribute__((no-errno("__ieee754_sin"))); and
with -fno-math-errno we could redirect calls to the no-errno alias
instead. But I'm veering off-topic here.
Richard.
