[RFA][PATCH][pr target/60648] Fix non-canonical RTL from x86 backend -- P1 regression

[Jeff Law]

On 03/26/14 12:28, Jakub Jelinek wrote:
> On Wed, Mar 26, 2014 at 12:17:43PM -0600, Jeff Law wrote:
>> On 03/26/14 12:12, Jakub Jelinek wrote:
>>> On Wed, Mar 26, 2014 at 11:02:48AM -0600, Jeff Law wrote:
>>>> Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
>>>> Verified it fixes the original and reduced testcase.
>>>
>>> Note, the testcase is missing from your patch.
>>>
>>> But I'd question if this is the right place to canonicalize it.
>>> The non-canonical order seems to be created in the generic code, where
>>> do_tablejump does:
>> No, at that point it's still canonical because the x86 backend
>> hasn't simpified the (mult ...) subexpression.  Its the
>> simplification of that subexpression to a constant that creates the
>> non-canonical RTL.  That's why I fixed the x86 bits -- those are the
>> bits that simplify the (mult ...) into a (const_int) and thus
>> creates the non-canonical RTL.
>
> (mult:SI (const_int 0) (const_int 4)) is IMHO far from being canonical.
It's debatable.  Our canonicalization rules don't explicitly cover the 
case where both arguments to a commutative expression are constants. 
Thus, I would classify that as legitimate, but unsimplified RTL.

Contrast to
(plus (const_int 0) (label_ref)

Which is clearly non-canonical.

Jeff