On Mon, Jun 4, 2018 at 8:32 AM Eric Botcazou wrote:
>
> Hi,
>
> the previous patch makes it possible to merge bit-field stores whose RHS is a
> constant or a SSA name, but there is a hitch: if the SSA name is the result of
> an "interesting" load, then the optimization is blocked. That's because
Hi,
the previous patch makes it possible to merge bit-field stores whose RHS is a
constant or a SSA name, but there is a hitch: if the SSA name is the result of
an "interesting" load, then the optimization is blocked. That's because the
GIMPLE store-merging pass not only attempts to merge stor
> Just a general remark, the many non-functional but stylistic changes do not
> make the patch easier to review ;)
Sorry about that (in this case the ChangeLog is supposed to help a little).
> + /* If bit insertion is required, we use the source as an
> accumulator +into which
On Fri, 1 Jun 2018, Richard Biener wrote:
> For code-generating adjacent inserts wouldn't it be more efficient
> to do
>
> accum = first-to-be-inserted-val;
> accum <<= shift-to-next-inserted-val;
> accum |= next-to-be-inserted-val;
> ...
> accum <<= final-shift;
>
> instead of shifting t
On Thu, May 31, 2018 at 3:25 PM Eric Botcazou wrote:
>
> Hi,
>
> this enhances the GIMPLE store-merging pass by teaching it to deal with
> generic stores to bit-fields, i.e. not just stores of immediates. The
> motivating example is:
>
> struct S {
> unsigned int flag : 1;
> unsigned int size
Hi,
this enhances the GIMPLE store-merging pass by teaching it to deal with
generic stores to bit-fields, i.e. not just stores of immediates. The
motivating example is:
struct S {
unsigned int flag : 1;
unsigned int size : 31;
};
void foo (struct S *s, unsigned int size)
{
s->flag = 1;
