Richard Biener <rguent...@suse.de> writes:
> On Wed, 22 Apr 2020, Richard Biener wrote:
>
>>
>> This extends DECL_GIMPLE_REG_P to all types so we can clear
>> TREE_ADDRESSABLE even for integers with partial defs, not just
>> complex and vector variables. To make that transition easier
>> the patch inverts DECL_GIMPLE_REG_P to DECL_NOT_GIMPLE_REG_P
>> since that makes the default the current state for all other
>> types besides complex and vectors. That also nicely simplifies
>> code throughout the compiler.
>>
>> TREE_ADDRESSABLE and DECL_NOT_GIMPLE_REG_P are now truly
>> independent, either set prevents a decl from being rewritten
>> into SSA form.
>>
>> For the testcase in PR94703 we're able to expand the partial
>> def'ed local integer to a register then, producing a single
>> movl rather than going through the stack.
>>
>> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>>
>> If there are no objections I'm going to install this once
>> stage1 opens.
>
> Of course there was some fallout. On 32bit x86 gcc.dg/torture/pr71522.c
> fails execution because while the GIMPLE is unchanged at RTL expansion
> time:
>
> main ()
> {
> char s[12];
> long double d;
>
> MEM <unsigned char[12]> [(char * {ref-all})&d] = MEM <unsigned char[12]>
> [(char * {ref-all})"AAAAAAAAAAA"];
> MEM <unsigned char[12]> [(char * {ref-all})&s] = MEM <unsigned char[12]>
> [(char * {ref-all})&d];
> _1 = __builtin_strcmp (&s, "AAAAAAAAAAA");
> if (_1 != 0)
> ...
>
> we now assign 'd' an XFmode register (TREE_ADDRESSABLE is cleared
> now since we can set DECL_NOT_GIMPLE_REG_P). The case is lost
> then, impossible to fix up AFAICS. On x86 all moves to/from
> XFmode are normalizing, specifically we end up with
>
> fldt .LC0
> fstpt (%esp)
>
> now the most appealing solution - and totally in the opposite
> direction of this patch - is to simply stop expanding non-SSA names
> as pseudos. I do not remember the history as why we do this
> but it's likely remanents we preserved from either pre-SSA, times
> we did not go into SSA for -O0 or times we really gone out-of-SSA.
>
> There is _some_ good reason to expand a non-SSA "register" into
> a pseudo though - namely that RTL is not SSA and thus can accept
> partial defs. And of course that RTL cannot get rid of a stack
> slot assigned to a variable. Today we have somewhat robust
> infrastructure to deal with partial defs on GIMPLE, namely
> BIT_INSERT_EXPR, but it's not fully exercised.
Yeah, not being able to get rid of the stack slot seems
worrying here.
> It's of course possible to fixup the above problematical
> cases (there's precenent with discover_nonconstant_array_refs,
> which could be "easily" extended to handle "weird" accesses
> of non-integral-mode variables) but with the recent discussion
> on making RTL expansion more straight-forward I'd bring up
> the above idea ... it would get rid of quite some special
> code dealing with tcc_reference trees (and MEM_REFs) ending
> up operating on registers.
It might be nice to do it eventually, but I think at least
is_gimple_reg_type would need to be "return true" first,
otherwise we'll lose too much on aggregates.
There's also the problem that things passed in registers do need
to be RTL registers at function boundaries, so I'm not sure all
the expand code would necessarily go away.
Wouldn't want to see all targets suffer for XFmode oddities :-)
Thanks,
Richard
