> I suppose I was putting too much store by the expmed.c code. How does
> this version look? Tested on x86_64-linux-gnu, powerpc64-linux-gnu
> and cris-elf.
>
> Richard
>
>
> gcc/
> PR middle-end/55438
> * expmed.c (simple_mem_bitfield_p): New function, extracted from
> store
Eric Botcazou writes:
>> OK, how about:
>>
>> /* ??? For historical reasons, reject modes that would normally
>> receive greater alignment, even if unaligned accesses are
>> acceptable. This has both advantages and disadvantages.
>
> Fine with me.
>
>> I think here we rea
Eric Botcazou writes:
> We could conceivably have an aligned mode with bitsize 32 and alignment 16
> (i.e. STRICT_ALIGNMENT 1 and BIGGEST_ALIGNMENT 16), meaning that we can use
> 16-bit aligned 32-bit chunks in this mode.
That's actually what m68k traditionally had.
Andreas.
--
Andreas Schw
> OK, how about:
>
>/* ??? For historical reasons, reject modes that would normally
> receive greater alignment, even if unaligned accesses are
> acceptable. This has both advantages and disadvantages.
Fine with me.
> I think here we really do want unit (i.e. the GET
Eric Botcazou writes:
>> In http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00257.html I said:
>>
>> get_best_mode has various checks to decide what counts as an acceptable
>> bitfield mode. It actually has two copies of them, with slightly
>> different alignment checks:
>>
>> MIN (unit, B
> In http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00257.html I said:
>
> get_best_mode has various checks to decide what counts as an acceptable
> bitfield mode. It actually has two copies of them, with slightly
> different alignment checks:
>
> MIN (unit, BIGGEST_ALIGNMENT) > align
>
>
In http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00257.html I said:
get_best_mode has various checks to decide what counts as an acceptable
bitfield mode. It actually has two copies of them, with slightly different
alignment checks:
MIN (unit, BIGGEST_ALIGNMENT) > align
vs.
unit
