On Mon, Jun 20, 2011 at 1:54 PM, Richard Guenther
wrote:
> Yeah, well. We have mostly no target dependency in those gimple
> statement speed/size cost metric, so the above 3 is matching
> how the expansion to gimple shift/mask stmts would measure.
Except RTH has mentioned there is already a way
On Mon, Jun 20, 2011 at 8:43 PM, Andrew Pinski wrote:
> On Mon, Jun 20, 2011 at 7:19 AM, William J. Schmidt
> wrote:
>> On Thu, 2011-06-16 at 09:49 -0700, Richard Henderson wrote:
>>> On 06/16/2011 04:35 AM, Richard Guenther wrote:
>>> >
>>> > + /* Bit-field insertion needs several shift and
On Mon, Jun 20, 2011 at 7:19 AM, William J. Schmidt
wrote:
> On Thu, 2011-06-16 at 09:49 -0700, Richard Henderson wrote:
>> On 06/16/2011 04:35 AM, Richard Guenther wrote:
>> >
>> > + /* Bit-field insertion needs several shift and mask operations. */
>> > + case BIT_FIELD_EXPR:
>> > +
On Thu, 2011-06-16 at 09:49 -0700, Richard Henderson wrote:
> On 06/16/2011 04:35 AM, Richard Guenther wrote:
> >
> > + /* Bit-field insertion needs several shift and mask operations. */
> > + case BIT_FIELD_EXPR:
> > + return 3;
>
> ... depending on the target, of course.
>
Agre
Hi,
On Sun, 19 Jun 2011, William J. Schmidt wrote:
> At the risk of being obvious...it seems you could easily combine C1 and
> C2 into a single "bitfield descriptor" TREE_INT_CST operand by using
> both the high and low portions of the constant. Accessor macros could
> be used to hide the sli
On Thu, 2011-06-16 at 13:35 +0200, Richard Guenther wrote:
> This is a (possible) pre-requesite for the bitfield lowering patch,
> taken from the old mem-ref branch. It introduces BIT_FIELD_EXPR
> which can be used to do bitfield composition.
> BIT_FIELD_EXPR is equivalent to computing
> a & ~((1
On 06/16/2011 12:14 PM, Richard Guenther wrote:
> On Thu, Jun 16, 2011 at 7:24 PM, Eric Botcazou wrote:
>>> I think this would be clearer with a name like DEPOSIT_EXPR,
>>> similar to the ia64 deposit instruction.
>>
>> ia64's demise wasn't entirely undeserved then. IMO the descriptive power of
>
On Thu, Jun 16, 2011 at 7:24 PM, Eric Botcazou wrote:
>> I think this would be clearer with a name like DEPOSIT_EXPR,
>> similar to the ia64 deposit instruction.
>
> ia64's demise wasn't entirely undeserved then. IMO the descriptive power of
> DEPOSIT_EXPR is almost null. BIT_FIELD_MODIFY_EXPR o
> I think this would be clearer with a name like DEPOSIT_EXPR,
> similar to the ia64 deposit instruction.
ia64's demise wasn't entirely undeserved then. IMO the descriptive power of
DEPOSIT_EXPR is almost null. BIT_FIELD_MODIFY_EXPR or something like this.
--
Eric Botcazou
On 06/16/2011 04:35 AM, Richard Guenther wrote:
>
> This is a (possible) pre-requesite for the bitfield lowering patch,
> taken from the old mem-ref branch. It introduces BIT_FIELD_EXPR
> which can be used to do bitfield composition.
> BIT_FIELD_EXPR is equivalent to computing
> a & ~((1 << C1 -
> BIT_FIELD_EXPR is equivalent to computing
> a & ~((1 << C1 - 1) << C2) | ((b << C2) & (1 << C1 = 1)),
a & ~(((1 << C1) - 1) << C2) | ((b & ((1 << C1) - 1)) << C2)
?
Jay.
thus
> inserting b of width C1 at the bitfield position C2 in a, returning
> the new value. This allows translating
> B
This is a (possible) pre-requesite for the bitfield lowering patch,
taken from the old mem-ref branch. It introduces BIT_FIELD_EXPR
which can be used to do bitfield composition.
BIT_FIELD_EXPR is equivalent to computing
a & ~((1 << C1 - 1) << C2) | ((b << C2) & (1 << C1 = 1)), thus
inserting b o
12 matches
Mail list logo
