> On 06/25/14 21:38, Kito Cheng wrote:
> >For example in arm-elf-eabi, movmem need word align, otherwise it will
> >expand a libcall:
> >
> >And gcc configure with "--target=arm-elf-eabi --disable-nls
> >--disable-shared --enable-languages=c,c++ --enable-threads=single
> >--enable-lto --with-newlib"
> >
> >test.c:
> >extern bar(unsigned char p[3][2]);
> >void foo(int i)
> >{
> > unsigned char data[3][2] = {{1,1}, {1,0}, {1,1}};
> >
> > bar(data);
> >}
> First, note, I'm not an ARM expert. However, the first question I
> have is are we sure the initializer is always going to be suitably
> aligned? What guarantees this initializer is going to have 32 bit
On not so related note, vectorizer knows everything about how to increase
alignment of a declaration (not in constant pool for now, because that one is
riddled by implementation defaults) on demand. It would be nice to teach
string operation expanders to do so when they think it helps.
(see vect_can_force_dr_alignment_p)
> alignment like you want? I can see how that *section* gets its
> alignment, but I don't offhand see what in the ARM backend ensures
> that a CONSTRUCTOR tree has larger than normal known alignment.
I think those boil down into CONSTANT_DECL that is aligned by DATA_ALIGNMENT.
But it would be great to have API to boos these up on the demand.
I find the whole macro macinery around memcpy/memset bit difficult - one think
I would like it do to is this trick, other thing is to allow vector registers to
be used by COPY_BY_PIECES.
Honza
>
> I think that needs to be settled first, then we need to verify that
> the trees are correctly carrying that alignment requirement around
> and that the code uses it appropriately (and I have my doubts
> because EXP is a CONSTRUCTOR element and those seem to be largely
> ignored in the code we're looking to change).
>
> I would also strongly recommend turning your testcase into something
> we can add to the testsuite.
>
> If you look in gcc/testsuite/gcc.target/arm you'll see several
> examples. I think you just want to compile this down to assembly
> code with the optimizer enabled, then verify there is no call to
> memcpy in the resulting output. 20030909-1.c would seem to be a
> reasonable example of a test that does something similar.
>
>
> Jeff
