GIMPLE types merging in LTO compiler
Hi, most of the remaining warnings issued by the LTO compiler on object files compiled from Ada are caused by a small flaw in the GIMPLE types merging process: it is done before symbols are merged so compatible types (typically domain types of arrays) whose distinguishing features depend on symbols (variable bounds for domain types of arrays) aren't recognized as such if the first type references one instance of the symbol (e.g. the prevailing one) and the second type references another instance of the same symbol. What's the best approach to addressing this? Thanks in advance. -- Eric Botcazou
Re: GIMPLE types merging in LTO compiler
On Fri, May 14, 2010 at 1:24 PM, Eric Botcazou ebotca...@adacore.com wrote: Hi, most of the remaining warnings issued by the LTO compiler on object files compiled from Ada are caused by a small flaw in the GIMPLE types merging process: it is done before symbols are merged so compatible types (typically domain types of arrays) whose distinguishing features depend on symbols (variable bounds for domain types of arrays) aren't recognized as such if the first type references one instance of the symbol (e.g. the prevailing one) and the second type references another instance of the same symbol. What's the best approach to addressing this? Thanks in advance. Ugh. This presents a chicken-and-egg problem to symbol resolution and type-merging. To be clear, the issue is sth like unit1 - int size; int a[size]; unit2 -- extern int size; extern a[size]; ? And you get the a's merged but a diagnostic about mismatched types? One way to fix this would be to simply detect the situation and never issue a diagnostic. Another way would be to delay the diagnostics until after all types and symbols are merged. The natural place for this would be lto_symtab_merge_cgraph_nodes () which already is after type merging and still has all candidates available. Richard. -- Eric Botcazou
Re: GIMPLE types merging in LTO compiler
Ugh. This presents a chicken-and-egg problem to symbol resolution and type-merging. To be clear, the issue is sth like unit1 - int size; int a[size]; unit2 -- extern int size; extern a[size]; ? And you get the a's merged but a diagnostic about mismatched types? Yes, exactly. One way to fix this would be to simply detect the situation and never issue a diagnostic. Another way would be to delay the diagnostics until after all types and symbols are merged. The natural place for this would be lto_symtab_merge_cgraph_nodes () which already is after type merging and still has all candidates available. Is suppressing the diagnostic sufficient? Will the two types be merged after the symbols are unified, or does that not matter at all? -- Eric Botcazou
Re: GIMPLE types merging in LTO compiler
On Fri, May 14, 2010 at 9:33 PM, Eric Botcazou ebotca...@adacore.com wrote: Ugh. This presents a chicken-and-egg problem to symbol resolution and type-merging. To be clear, the issue is sth like unit1 - int size; int a[size]; unit2 -- extern int size; extern a[size]; ? And you get the a's merged but a diagnostic about mismatched types? Yes, exactly. One way to fix this would be to simply detect the situation and never issue a diagnostic. Another way would be to delay the diagnostics until after all types and symbols are merged. The natural place for this would be lto_symtab_merge_cgraph_nodes () which already is after type merging and still has all candidates available. Is suppressing the diagnostic sufficient? Will the two types be merged after the symbols are unified, or does that not matter at all? The types will not be unified. We are currently inserting VIEW_CONVERT_EXPRs to make the IL type verification happy, but in the end it will cause broken type-based alias info and thus may trigger miscompiles. I am in the process of fixing both pieces (avoid the V_C_E by using MEM_REF and avoid the miscompile by separating TBAA types from the IL types). Richard. -- Eric Botcazou
Re: GIMPLE types merging in LTO compiler
On Fri, May 14, 2010 at 9:33 PM, Eric Botcazou ebotca...@adacore.com wrote: Ugh. This presents a chicken-and-egg problem to symbol resolution and type-merging. To be clear, the issue is sth like unit1 - int size; int a[size]; unit2 -- extern int size; extern a[size]; ? And you get the a's merged but a diagnostic about mismatched types? Yes, exactly. One way to fix this would be to simply detect the situation and never issue a diagnostic. Another way would be to delay the diagnostics until after all types and symbols are merged. The natural place for this would be lto_symtab_merge_cgraph_nodes () which already is after type merging and still has all candidates available. Is suppressing the diagnostic sufficient? Will the two types be merged after the symbols are unified, or does that not matter at all? The types will not be unified. We are currently inserting VIEW_CONVERT_EXPRs to make the IL type verification happy, but in the end it will cause broken type-based alias info and thus may trigger miscompiles. I am in the process of fixing both pieces (avoid the V_C_E by using MEM_REF and avoid the miscompile by separating TBAA types from the IL types). Also while working on this, please keep in mind that for data layout optimization we desperately need to have all accesses to the same memory object to have same type so we can rewrite it. ipa-struct-reorg is currently doing some pretty lame type combining based on type names for --combine, but we need sane framework for this. Honza
