This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Some middle-end improvements for bitfield handling


On Wed, 30 Jun 2004, Jakub Jelinek wrote:
> On Tue, Jun 29, 2004 at 02:46:46PM -0600, Roger Sayle wrote:
> > > 	* simplify-rtx.c (simplify_binary_operation): Simplify
> > > 	((A & N) + B) & M -> (A + B) & M if M is pow2 minus 1 constant and
> > > 	N has at least all bits in M set as well.
> > >
> > > 	* expr.c (expand_assignment): Optimize += or -= on a bit field in
> > > 	most significant bits.
> > >
> > > 	* gcc.c-torture/execute/20040629-1.c: New test.
> >
> > This is OK for mainline.  Could you try these changes on the testcases
> > given in PR tree-optimization/15310, and see if that PR can be closed?
>
> Didn't know we have PRs for just about everything ;)
> Both testcases are optimized into addl    $2, sdata(%rip); ret on x86-64
> with this patch.

Cool.  Thanks.


> Looking through the mails which lead to PR 15310, your one-bit
> bitfield handling could be doable with a smallish change to
> expand_assignment too.  Just handle bitsize == 1 with constant
> TREE_OPERAND (from, 1) in addition to count + bitsize == GET_MODE_BITSIZE ().
> Shall I prepare a patch for that?

That would be great!  This has been on my TODO list for a while.


> Another optimization would be to use ROTATE instructions if available:
> Not sure if it wouldn't be better to expose bitfields operations
> alreary during gimplification or somewhere in the middle of tree-ssa
> passes though, i.e. rtl expanders would only see shifting/masking etc.
> and tree-ssa passes could already optimize.

Not only is there the philosphical issue of whether to expose bitfield
mechanics to tree-ssa, but this is also approaching territory where
we'll need target_tree_cost or similar, as rotates are significantly
more expensive on some platforms than others.  The best possible
solution is to try and catch these things during RTL expansion, whilst
we still have the trees, but can ask the backend about RTL preferences.
As you point out, these transformations affect too many instructions
to be done in combine.


Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]