Re: [PATCH, ARM] stop changing signedness in PROMOTE_MODE

[Richard Earnshaw <Richard.Earnshaw@foss.arm.com>]

On 13/07/15 16:29, Michael Matz wrote:
> Hi,
> 
> On Mon, 13 Jul 2015, Richard Biener wrote:
> 
>> On Fri, Jul 10, 2015 at 5:46 PM, Jim Wilson <jim.wilson@linaro.org> wrote:
>>> On Tue, Jul 7, 2015 at 2:35 PM, Richard Biener
>>> <richard.guenther@gmail.com> wrote:
>>>> On July 7, 2015 6:29:21 PM GMT+02:00, Jim Wilson <jim.wilson@linaro.org> wrote:
>>>>> signed sub-word locals.  Thus to detect the need for a conversion, you
>>>>> have to have the decls, and we don't have them here.  There is also
>>>>
>>>> It probably is.  The decks for the parameter based SSA names are available, for the PHI destination there might be no decl.
>>>
>>> I tried looking again, and found the decls.  I'm able to get correct
>>> code for my testcase with the attached patch to force the conversion.
>>> It is rather inelegant, but I think I can cache the values I need to
>>> make this simpler and cleaner.  I still don't have decls from
>>> insert_part_to_rtx_on_edge and insert_rtx_to_part_on_edge, but it
>>> looks like those are for breaking cycles, and hence might not need
>>> conversions.
>>
>> Yes, that looks like a defect.  CCing Micha who wrote this code
> 
> I think it's a backend bug that parameters and locals are extended 
> differently.  The code in tree-outof-ssa was written with the assumption 
> that the modes of RTL objects might be different (larger) than the tree 
> types suggest, but that they be _consistent_, i.e. that the particular 
> extension depends on only the types, not on the tree-type of the decl.
> 

We went through this a couple of weeks back.  The backend documentation
for PROMOTE_MODE says:

" For most machines, the macro definition does not change @var{unsignedp}.
However, some machines, have instructions that preferentially handle
either signed or unsigned quantities of certain modes.  For example, on
the DEC Alpha, 32-bit loads from memory and 32-bit add instructions
sign-extend the result to 64 bits.  On such machines, set
@var{unsignedp} according to which kind of extension is more efficient."

So clearly it anticipates that all permitted extensions should work, and
in particular it makes no mention of this having to match some
abi-mandated promotions.  That makes this a MI bug not a target one.

R.


> I think the above assumption does make sense because it's also a 
> fundamental assumption in the whole gimple pipeline, types matter, not the 
> objects (or better, we slowly but surely work towards this).  Hence such 
> mismatches should either not exist (changing the backend), or should be 
> exposed explicitely during gimplification already.  The latter is a large 
> change, though.
> 
> I think dealing with this situation in outof-ssa is a hack and I don't 
> like it.  It would extend the ugliness of different modes for same types 
> even more, and that's something we should (gradually) move away from.
> 
> 
> Ciao,
> Michael.
>