Re: mspgcc "undefines" too-many-bits shifts in weird way

Hello,

On Mon, 22 Apr 2013 08:12:50 -0500
Peter Bigot <[email protected]> wrote:

> Changes to mspgcc are/were driven by tickets filed on the SF bug
> tracker. If you'd like this change made after reading the material
> below, please file a ticket there.  mspgcc evolution/maintenance is
> not funded at this time and the issue is below the threshold that I
> consider critical enough to donate time, so the ticket will remain
> open until somebody takes over such maintenance.

Submitted: https://sourceforge.net/p/mspgcc/bugs/351/ . I actually
didn't want to spend too much time on this, or call for immediate
actions, just point out that there're better choices for
implementation-defined behavior as implemented mspgcc. I personally
don't expect any immediate changes, the whole idea was to save novices
or folks who may port big software from unneeded headache.

> For the record, I've reconstructed my reasoning from two years ago,
> which makes explicit the point Przemek made.  It's not worth the
> research to prove it, but again this was justified by similar
> practices in other gcc back-ends, even if not x86.
> 
> First, the value of a shift expression should be the same whether it
> is computed at compile time or at runtime.  

Well, it's the same thing - standard doesn't require this ;-). I
understand benefit of consistency, but given the choices (both
sanctioned by standard, as it simply underfines the case completely):

1. Make runtime & compile-time be consistent.
2. Make compile-time be consistent with mathematical definition, and
leave runtime to be optimal for particular h/w.

- It hopefully easier to make a choice. If not, then good exercise may
be to stop thinking about particular embedded CPU and all quirks which
can be done in its realm, but think about a compiler in general, and
that metaprogramming is important thing for producing optimal code
(especially for embedded targets!), and metapgramming requires robust
compile-time evaluation.

> I.e., 1 << 16 should
> produce the same value as 1 << v when v has the value 16.
> 
> Second, the base MSP430 ISA does not have a multi-position shift
> operation like x86 does.  It can shift only one bit position at a
> time.

Exactly, so masking out bits in shift counter wasn't even
hardware-bound (I don't know much about MSP430X), but more or less
arbitrary choice.

> Variable shifts must be translated into loops with the
> iteration count provided at runtime.  (Second-prime: use of MSP430X
> which has a limited version of such instructions should also not
> result in a change of the value of the shift expression.)

Oops, here you appear to want even more than I: I want just
math-guided rules for builtin GCC calculator, you want to generate
same-behaving code for different ISAs, at the potential expense of
runtime-efficiency. Hmm...

> Third, it is unreasonable when v has the value 63532 to stall the
> processor for 65532 iterations of a loop calculating 1 << v.  Instead
> the runtime code should limit the iteration count.  Since the maximum
> number of iterations before the expression value becomes a constant
> (i.e., the number of bits in the expression value) will always be a
> known power of two, masking the iteration count to preserve only the
> low bits from 0 to that number is the simplest solution.

Whoa, so you generate non-optimal code for the slight possibility that
someone shifts stuff 63532 times? That clearly goes against what
Przemek wrote (and with what I wholly agree, as my suggestions are
solely for compile-time behavior). If a programmer wants to shoot
oneself in the feet, don't preclude one from doing that, just give a
good gun which will shoot in the feet, not suddenly in the opposite
direction ;-).

> This is the behavior mspgcc currently uses.  To accommodate your
> request a test would have to be added at runtime to see whether the
> iteration count is equal to or greater than the number of bits in the
> expression value, and if so to substitute the constant (0 or ~0) that
> would have resulted from the shift operation.  This introduces code
> bloat, as in the vast majority of cases people will not be using a
> shift count that is large enough to trigger the conditional.
> 
> In my opinion increasing generated code size just to accommodate a
> practice that is explicitly undefined behavior is a poor use of
> resources and improperly encourages a misunderstanding of how C
> treats this situation. Having considered the arguments, no, the
> behavior will not be changed.

So once again, I was talking about changing *only* compile-time time
behavior, runtime doesn't need to change (except that, as a separate
issue, I'd vote for removing any extra masking during runtime shifts -
programmer either took care of that by masking count oneself, knows
that it's invariantly in range, or well, wants to shift 60K times).

> Please note that the new back end under development by Red Hat may
> have different behavior.
> 
> Peter
> 
> 
> On Sun, Apr 21, 2013 at 6:10 PM, Paul Sokolovsky <[email protected]>
> wrote:
> 
> > Hello,
> >
> > On Sun, 21 Apr 2013 17:06:51 -0500
> > Peter Bigot <[email protected]> wrote:
> >
> > > This decision was intentional, as documented in
> > > https://sourceforge.net/p/mspgcc/bugs/118/.  My recollection is
> > > that the choice of how to make things consistent was informed by
> > > similar behavior in the contemporaneous gcc for x86 or at least
> > > one other target architecture.
> >
> > Thanks for the reference. So, I tested it with x86 gcc 4.4, 4.5,
> > 4.6, 4.7 (packages as shipped by Ubuntu), all of them produce
> > mathematically expected result. msp430-gcc 4.5.3, 4.7.0 both
> > produce unexpected result.
> >
> > > As you say, the behavior is undefined.  Anybody who expects any
> > > particular behavior for this situation is confused about how C
> > > works and should take the issue up with JTC1/SC22/WG14.
> >
> > That's why I wrote so many words in the original mail. Yes, in small
> > world of JTC1/SC22/WG14 C standard the behavior is undefined. But in
> > much bigger world of: mathematics, well-known gcc targets, user
> > expectations, principle of least surprise, etc. - it's all pretty
> > well defined. So, when something is undefined in small area, it's
> > still a good idea to have affinity towards how it's done/expected
> > in wider areas. So, the request is just that - please kindly
> > consider changing that behavior ;-).
> >
> > >
> > > Peter
> > >
> >
> > --
> > Best regards,
> >  Paul                          mailto:[email protected]
> >



-- 
Best regards,
 Paul                          mailto:[email protected]

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter