[Bug middle-end/91131] Bad bitfield coalescing

pdj at knaldgas dot dk gcc-bugzilla@gcc.gnu.org
Thu Jul 11 09:56:00 GMT 2019


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91131

--- Comment #9 from Per Dalgas Jakobsen <pdj at knaldgas dot dk> ---
(In reply to Richard Biener from comment #8)
> Fixed on trunk sofar.
> 
> Note the non-optimal code-gen probably was a side-effect of us making
> three volatile accesses out of one.  On x86 I now see
> 
> main:
> .LFB0:
>         .cfi_startproc
>         movl    $0, Reg_A(%rip)
>         xorl    %eax, %eax
>         movl    $8, Reg_B(%rip)
>         movl    $255, Reg_C(%rip)
>         movb    $0, Reg_D(%rip)
>         movb    $-1, Reg_E(%rip)
>         ret

That's as efficient as it gets :)

On AVR architecture I now get this:
avr-gcc -O0:
        andi    r25, 0xF8       ; 248
        andi    r25, 0xF7       ; 247
        andi    r25, 0x0F       ; 15
        sts     0x0064, r25     ; 0x800064 <Reg_A>
        andi    r24, 0xF8       ; 248
        ori     r24, 0x08       ; 8
        andi    r24, 0x0F       ; 15
        sts     0x0065, r24     ; 0x800065 <Reg_B>
        lds     r24, 0x0060     ; 0x800060 <__data_start>
        sts     0x0063, r24     ; 0x800063 <Reg_C>
        sts     0x0066, r1      ; 0x800066 <Reg_D>
        ldi     r24, 0xFF       ; 255
        sts     0x0062, r24     ; 0x800062 <__data_end>

avr-gcc -O3 (and -Os, -O1, -O2):
        sts     0x0064, r1      ; 0x800064 <Reg_A>
        ldi     r24, 0x08       ; 8
        sts     0x0065, r24     ; 0x800065 <Reg_B>
        lds     r24, 0x0060     ; 0x800060 <__data_start>
        sts     0x0063, r24     ; 0x800063 <Reg_C>
        sts     0x0066, r1      ; 0x800066 <Reg_D>
        ldi     r24, 0xFF       ; 255
        sts     0x0062, r24     ; 0x800062 <__data_end>

Nice improvement, but Reg_C is still loading from memory. Is it possible to get
that into an immediate as well?

I'm slightly surprised that -O0 shows the setting of individual fields. It's
certainly not a bug, perhaps not even an issue, and absolutely something I can
live with :)


> as of using a packed structure the reason it might be problematic is that
> this lowers its alignment to 1 byte.  There are architectures that cannot
> do unaligned accesses so when the bitfield spans more than one byte the
> access might need to be decomposed.  Using an aligned attribute in addition
> to the packed attribute and aligning the structure appropriately would be
> a solution to this issue.

Ah, got it, thanks!


More information about the Gcc-bugs mailing list