On 9/13/18 4:01 AM, Andrew Stubbs wrote:
>
> The register that find_rename_reg is considering is SCC, which is one of
> the "special" registers. There is a short-cut in rename_chains for
> fixed registers, global registers, and frame pointers. It does not
> check HARD_REGNO_RENAME_OK.
I wonder
On 9/13/18 8:08 AM, Andrew Stubbs wrote:
> On 13/09/18 11:01, Andrew Stubbs wrote:
>> The assert is caused because the def-use chains indicate that SCC
>> conflicts with itself. I suppose the question is why is it doing that,
>> but it's probably do do with that being a special register that gets
> On Sep 13, 2018, at 10:58 AM, Andrew Stubbs wrote:
>
> On 13/09/18 15:49, Paul Koning wrote:
>> It's ambiguous, because the last sentence of that paragraph says "addm3 is
>> used if addptrm3 is not defined."
>
> I didn't read that as ambiguous; I read it as addm3 is assumed to work fine
On 13/09/18 15:49, Paul Koning wrote:
It's ambiguous, because the last sentence of that paragraph says "addm3 is used if
addptrm3 is not defined."
I didn't read that as ambiguous; I read it as addm3 is assumed to work
fine when addptr is not defined.
I don't know of any change in this
> On Sep 13, 2018, at 10:39 AM, Andrew Stubbs wrote:
>
> On 13/09/18 15:16, Paul Koning wrote:
>> If you don't have machine operations that add without messing with
>> condition codes, wouldn't it make sense to omit the definition of the
>> add-pointer patterns? GCC will build things out of
On 13/09/18 15:16, Paul Koning wrote:
If you don't have machine operations that add without messing with
condition codes, wouldn't it make sense to omit the definition of the
add-pointer patterns? GCC will build things out of normal
(CC-clobbering) adds if there are no add-pointer operations,
> On Sep 13, 2018, at 10:08 AM, Andrew Stubbs wrote:
>
> On 13/09/18 11:01, Andrew Stubbs wrote:
>> The assert is caused because the def-use chains indicate that SCC conflicts
>> with itself. I suppose the question is why is it doing that, but it's
>> probably do do with that being a
On 13/09/18 11:01, Andrew Stubbs wrote:
The assert is caused because the def-use chains indicate that SCC
conflicts with itself. I suppose the question is why is it doing that,
but it's probably do do with that being a special register that gets
used in split2 (particularly by the addptrdi3
On 12/09/18 12:29, Andrew Stubbs wrote:
I'll report back when I've done more testing.
I reproduced the problem, in the latest sources, with the
SPECIAL_REGNO_P patch removed (and HARD_REGNO_RENAME_OK adjusted
accordingly).
Testcase: gcc.c-torture/compile/20020706-2.c -O3 -funroll-loops
On 12/09/18 16:31, Richard Henderson wrote:
How is this different from HARD_REGNO_RENAME_OK via the TO argument?
Seems like the hook you're looking for already exists...
I don't know how we got here (I didn't do the original work), but the
SPECIAL_REGNO_P was indeed used in
On 09/05/2018 04:48 AM, a...@codesourcery.com wrote:
> @@ -1198,6 +1198,10 @@ see the files COPYING3 and COPYING.RUNTIME
> respectively. If not, see
> #define NO_FUNCTION_CSE false
> #endif
>
> +#ifndef SPECIAL_REGNO_P
> +#define SPECIAL_REGNO_P(REGNO) false
> +#endif
> +
> #ifndef
On 11/09/18 23:42, Jeff Law wrote:
This feels like you're papering over a problem in regrename and/or the
GCN port.. regrename should be checking the predicate and constraints
when it makes changes. And I think that you're still allowed to refer
to a fixed register in alternatives.
I think
On 9/5/18 5:48 AM, a...@codesourcery.com wrote:
>
> GCN has some registers which are special purpose, but not "fixed" because we
> want the register allocator to track their usage and select alternatives that
> use different special registers (e.g. scalar cc vs. vector cc).
>
> Sometimes this
On Wed, 5 Sep 2018, a...@codesourcery.com wrote:
> This patch creates a new macro SPECIAL_REGNO_P which disables regrename. In
> other words, the register is fixed once allocated.
Creating new target macros is generally suspect - the presumption is that
target hooks should be used instead,
GCN has some registers which are special purpose, but not "fixed" because we
want the register allocator to track their usage and select alternatives that
use different special registers (e.g. scalar cc vs. vector cc).
Sometimes this leads the regrename pass to ICE. Quite how it gets confused
15 matches
Mail list logo
