FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr)

[Ian Lepore]

It shouldn't be padding, the pointer is aligned correctly.  The problem
is that it's optimizing a pair of word stores into a single doubleword
store when the alignment of the pair doesn't allow that optimization.
Some arm hardware allows unaligned access, other hardware doesn't, so
maybe we should be setting some clang optimization flag to let it know
what's legal for the target platform?

-- Ian

On Fri, 2012-12-28 at 08:47 -0800, Adrian Chadd wrote:
> .. the compiler should know the alignment for each of those types and
> pad the structure appropriately, right?
> 
> david - what's the "right" behaviour here? Surely clang should be
> inserting 4 bytes of padding before that pointer?
> 
> 
> 
> Adrian
> 
> 
> On 28 December 2012 08:41, Daisuke Aoyama <aoyama at peach.ne.jp> wrote:
> >>>> This is complete version of systimer patch.
> >>>> It should fix stopping interrupt and related things such as USB LAN is
> >>>> unstable,
> >>>> SSH is closed suddenly.
> >>>> (I've not yet finished all test at this time, but at least portsnap
> >>>> fetch is
> >>>> success.
> >>>> Now extracting the ports without any problems.)
> >
> >
> > Finished without any problems.
> >
> >
> > I'm checking the alignment of clang now. It seems no difference of location
> > of data structure.
> > However, access method is different.
> >
> > I learned clang will combine two loads into one op.
> > This is a reason why the alignment seems difference between clang and gcc.
> > Also, a reason why clang binary is smaller than gcc code.
> >
> > According to ARM manual, strd alignment is:
> > "The address must be a multiple of eight for doubleword transfers."
> >
> > uboot/lib/api_public.h:
> > ----------------------------------------------------------------------
> > struct sys_info {
> >        unsigned long           clk_bus;
> >        unsigned long           clk_cpu;
> >        unsigned long           bar;
> >        struct mem_region       *mr;    /* << mr offset is 12!! (not DW
> > aligned) */
> >        int                     mr_no;  /* number of memory regions */
> > };
> >
> > uboot/lib/glue.c:
> > ----------------------------------------------------------------------
> > struct sys_info *
> > ub_get_sys_info(void)
> > {
> >        int err = 0;
> >
> >        memset(&si, 0, sizeof(struct sys_info));
> >        si.mr = mr;
> >        si.mr_no = UB_MAX_MR;
> >        memset(&mr, 0, sizeof(mr));
> >
> >        if (!syscall(API_GET_SYS_INFO, &err, (u_int32_t)&si))
> >                return (NULL);
> >
> >        return ((err) ? NULL : &si);
> > }
> >
> > ----------------------------------------------------------------------
> > clang -O2 output (7 steps):
> >        bl      memset            ; ATPCS uses r0-r3 as parameters
> >        ldr     r0, .LCPI6_1      ; mr
> >        mov     r1, #5            ; UB_MAX_MR
> >        mov     r2, #60           ; sizeof(mr)
> >        strd    r0, r1, [r5, #12] ; r5 aligned but strd requires DW(8byte)
> > alignment (faulted here)
> >        mov     r1, #0
> >        bl      memset            ;  memset(&mr, 0, sizeof(mr));
> >
> > clang final binary size(2.8% smaller):
> > -rwxr-xr-x  1 root  wheel  235984 Dec 28 23:49 ubldr
> > ----------------------------------------------------------------------
> > gcc 4.2 -O2 output (9 steps):
> >        bl      memset            ; ATPCS uses r0-r3 as parameters
> >        ldr     ip, .L162+4       ; mr
> >        mov     r3, #5            ; UB_MAX_MR
> >        mov     r1, r4            ; r4 is zero
> >        mov     r0, ip            ; << what??
> >        mov     r2, #60           ; sizeof(mr)
> >        str     r3, [r6, #16]     ; r6 aligned same as clang
> >        str     ip, [r6, #12]     ; r6 aligned same as clang
> >        bl      memset            ;  memset(&mr, 0, sizeof(mr));
> >
> > gcc final binary size:
> > -rwxr-xr-x  1 root  wheel  242810 Dec 28 18:22 ubldr
> > ----------------------------------------------------------------------
> > I don't know gcc 4.3 or newer, but probably output is more smart.
> > It seems that there is no reason to use ip in this case.
> >
> > Does any one know how to prevent above clang output?
> > (or how to solve this issue for all codes.)
> >
> > Thanks
> >
> > --
> > Daisuke Aoyama
> >
> >
> > _______________________________________________
> > freebsd-arm at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> > To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"