>loads of diff alignment should not share the same coderep.
It is supposed to be so, but in reality...
In the case I gave, what if wopt didn't know the two loads actually have
different alignment before codemap, and later on a data flow analysis
reveals the fact that one of them actually can have more stringent alignment
than what it had. What do you want to do in this case, reverse codemap?
> WOPT should not need to deal with alignment period. That belong elsewhere
What exactly does the "deal with" mean? WOPT have to respect the alignment
the upstream optimizers pass to it.
If you don't consider "respect" as one kind of "deal with". Consider this
case: someone want to see if *p is at least 16 byte aligned.
Why he/she is not supposed to perform that analysis in WOPT?
if (cond)
p = &a[0]; // align at 16byte boundary
else
p = &b[0] // 32-byte alignment
= *p;
>Two different places in symtab and type_idx to deal with alignment is just
bad.
This statement is very confusing. Are you using the "symtab" and "type_idx"
for the concept or the specific data structure in open64?
In order to avoid any confusion, I intentionally avoid any word about
"symbol" in the previous mail.
My point was "it is great to have alignment annotated to each memory
access".
Suppose you equate "symtab" with the data structure "ST", and "type_idx"
with data structure "TY"
I don't think the statement is 100% correct.
For the decl like following, there are two "types" involved.
int xyz __attribute__((aligned(16)).
The "base type" is int;
the variant-type/sub-type (whatever you call it) is
int-with-16-byte-alignment.
To represent the sub-type, one can either:
- create a totally independent type for the sub-type, and have the symbol
associated with it, or
- create a lean sub-type which only record the different from its base
type, and associate the symbol with the sub-type.
No matter which way you go for, if the sub-type and the base type diff in
alignment, you should record the alignments for both base-type and sub-type.
I'm totally lost about "it is just bad".
------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
