r225244 - Sema: analyze I,J,K,M,N,O constraints

[Joerg Sonnenberger]

On Thu, Jan 15, 2015 at 06:07:33PM +0000, Eric Christopher wrote:
> On Thu Jan 15 2015 at 4:23:00 AM Joerg Sonnenberger <joerg at britannica.bec.de>
> wrote:
> 
> > On Wed, Jan 14, 2015 at 02:44:44PM -0800, Reid Kleckner wrote:
> > > This change simply allows us to reject bad code earlier in a more user
> > > friendly way.
> >
> > How is it bad code or userfriendly? Have you looked at the inb example I
> > posted? Forcing macros is stupid and with ToT it is outright impossible
> > to produce optimal code. Yes, it depends on the optimizer to do a basic
> > job, so what?
> >
> >
> The problem is that if the argument to the function isn't actually constant
> then the front end won't be able to diagnose it and at best it'll get
> diagnosed in the back end or by the assembler.

The cases I tried are all diagnosed by the common codegen logic..

> The idea is that the front
> end handles these sorts of diagnostics and doesn't rely on optimization to
> happen to get them. We do have some support for back end diagnostics using
> front end locations - but I'm not sure we should use that here. Slippery
> slope and all. FWIW this fired a few times in our internal code base and we
> just fixed it up.

See the inb example. All fixes are pessimations for the code. People
complained enough about the (in)ability of __builtin_constant_p to get
it delayed to the backend, this is IMO just the same. This case is
especially annoying as it is not even a default-on warning.

Joerg