[RFA:] Don't strip unary ops when matching constraints. (PRtarget/23424)

[Joern RENNECKE]

Hans-Peter Nilsson wrote:

>
>I guess one way would be to save the assembly code and compare.
>Would you be happy with a test-run that does that for sh64,
>assuming a baseline builds?
>
Are you saying you expect the assembly code to be identical?  And what 
code base
were you intending to use for the comparison?

I'd be willing t accept identical code generation for EEMBC as evidence that
performance hasn't gone worse, or EEMBC benchmark results that do not 
regress.

>  (I'd argue that if a baseline
>doesn't build for a target, no further testing should be
>required.)
>  
>
Only if the failure to build is consistent over an extended period of 
time without
efforts by the port maintainer to get the situation resolved.  You can't 
say that
because a port has been recently broken by someone else, you are entitled to
break it beyond recoverability.

>Anyway, it seems far more likely that the bug is just waiting to
>happen for the SH port,
>
Why do you call the interface a bug?  You only have a bug if the port does
not agree with the interface.  If the target is such that you can't make 
them
agree without changing the interface, only then do you need to change the
interface in order to fix the bug on your target.

> than that fixing it would uncover a
>latent bug; particularly as you and presumably aoliva and others
>did not expect this unop-stripping when working on the port.
>  
>
I didn't expect this unop -stripping ad hoc, but I've encountered it and
dealt with it.  And subsequently I expected it.

>Would you be happy with the patch if I just write a test-case
>that exposes the bug for SH?
>  
>
I'd be intrigued to see a testcase that uncovers this bug you stipulate.
Still, if you find a bug affecting the sh64 port, we'd have to look at it
to decide how tit is properly fixed.

>>Yes, but if the way you fix this bug changes the interface for every 
>>port, how many
>>new bugs do you introduce?
>>    
>>
>
>None.  Like I said, when I looked, only CRIS and SH apparently
>are affected.
>  
>
Well, but you didn't test sh64.

>Only if those non-predicate occurrences also use constraints
>(which I'd argue would seem a bug by itself) and that shouldn't
>be very common.  I guess I could check for that.
>  
>
Even if the operand doesn't have a predicate, the instruction still 
might have one.
Remember, there are multi-alternative constraint sets, but no 
multi-alternative
interlocked predicate sets for the operand - you have to use an 
instruction predicate
to express that.

>If it wasn't clear, I *did* inspect other ports for
>unop-predicates with constraint uses.  I tested the main
>platforms I have easy access to.
>  
>
Obviously, your checking of the SH port did not go as far as figuring 
out where the
predicates are actually used, otherwise I wouldn't have had to tell you 
that the sh64
target needs to be tested.

>I don't really understand your reluctance for fixing this bug
>now: fixing a bug *always* has the possibility of uncovering
>other bugs.  Luckily, the number of ports affected by this bug
>and patch is very limited.
>  
>
See above: it's not a bug, it's an interface.