On Wed, May 6, 2009 at 9:17 PM, Richard Guenther
<[email protected]> wrote:
> On Wed, May 6, 2009 at 9:04 PM, Eric Botcazou <[email protected]> wrote:
>>> What is missing to go forward with this plan?
>>
>> Almost nothing, but I'm benchmarking the change and I'm seeing degradation in
>> some cases because move IVs are exposed and so are -fivopts' warts.
>>
>>> I am hitting type consistency problems again while trying to fix PR39999 ...
>>
>> Ideally this should be independent.
>
> Yes. But we have invalid IL before PRE (arithmetic in subtypes) and PRE
> manages
> to expose this fact in a way that type checking complains ... :/ I
> have now tested
> 4 variants of the obvious fix and all fail one way or the other
> because of this issue.
> For 4.4 it's easier because type checking won't notice it there ;)
I wonder for example about
<integer_type 0x2b1d770a3300 integer
type <integer_type 0x2b1d76cbe540 integer sizes-gimplified
asm_written public visited SI
size <integer_cst 0x2b1d76cb0a20 constant 32>
unit size <integer_cst 0x2b1d76cb0690 constant 4>
align 32 symtab 1993070176 alias set -1 canonical type
0x2b1d76cbe540 precision 32 min <integer_cst 0x2b1d76cb0990
-2147483648> max <integer_cst 0x2b1d76cb09c0 2147483647>
pointer_to_this <pointer_type 0x2b1d76ccc6c0>>
sizes-gimplified asm_written public visited SI size <integer_cst
0x2b1d76cb0a20 32> unit size <integer_cst 0x2b1d76cb0690 4>
align 32 symtab 2001622336 alias set 0 canonical type
0x2b1d770a3300 precision 32 min <integer_cst 0x2b1d76cb0990
-2147483648> max <integer_cst 0x2b1d76cb09c0 2147483647> RM size
<integer_cst 0x2b1d76cb0a20 32>
chain <type_decl 0x2b1d770a33c0 integer>>
it seems the base type here is exactly the same as the subtype?
In the particular case IVOPTs is creating arithmetic in that type. Or
maybe fold.
Richard.
