Re: [PATCH] middle-end IFN_ASSUME support [PR106654]

[Jakub Jelinek <jakub@redhat.com>]

On Fri, Oct 14, 2022 at 10:43:16PM +0200, Martin Uecker wrote:
> Am Montag, den 10.10.2022, 10:54 +0200 schrieb Jakub Jelinek:
> > Hi!
> > 
> > My earlier patches gimplify the simplest non-side-effects assumptions
> > into if (cond) ; else __builtin_unreachable (); and throw the rest
> > on the floor.
> > The following patch attempts to do something with the rest too.
> 
> My recommendation would be to only process side-effect-free
> assumptions and warn about the rest (clang does this for
> __builtin_assume).   I do not think this is worth the

I think that is bad choice and makes it useless.

> complexity and I am not so sure the semantics of a
> hypothetical evaluation are terribly well defined.

I think the C++23 paper is quite clear.  Yes, you can't verify it
in debug mode, but there are many other UBs that are hard to verify
through runtime instrumentation.
And, OpenMP has a similar feature (though, in that case it is even
a stronger guarantee where something is guaranteed to hold across
a whole region rather than just on its entry.

> That you can not verify this properly by turning it
> into traps in debug mode (as this would execute the
> side effects) also makes this a terrible feature IMHO.
> 
> MSVC which this feature was based does not seem to make
> much to sense to me: https://godbolt.org/z/4Ebar3G9b

So maybe their feature is different from what is in C++23,
or is badly implemented?
I think with what we have in the works for GCC we'll be able to optimize
in
int f(int i)
{
  [[assume(1 == i++)]];
  return (1 == i++);
}

int g(int i)
{
  [[assume(1 == ++i)]];
  return (1 == ++i);
}

extern int i;

int h(void) 
{
  [[assume(1 == ++i)]];
  return (1 == ++i);
}


int k(int i)
{
  [[assume(42 == ++i)]];
  return i;
}
at least f/g to return 1; and k to return 41;
The h case might take a while to take advantage of.

	Jakub