On 05/31/2015 07:03 PM, Alan Modra wrote:
I agree. Do you intend to get rid of WORD_REGISTER_OPERATIONS,
POINTERS_EXTEND_UNSIGNED, PUSH_ROUNDING, SHORT_IMMEDIATES_SIGN_EXTEND,
and LOAD_EXTEND_OP? ;-)
Oh yes, please. ;-)
Although for the specific case of this thread, W_R_O, S_I_S_E, and L_E_
On Tue, Jun 02, 2015 at 11:28:09AM -0500, Segher Boessenkool wrote:
> On Tue, Jun 02, 2015 at 08:49:37AM +0930, Alan Modra wrote:
> > but and64_2_operand doesn't include all of and_operand!
>
> Maybe I'm slow today, but I don't see it? Do you have an example?
I need to get new glasses. That's t
On Tue, Jun 02, 2015 at 08:49:37AM +0930, Alan Modra wrote:
> > > In and3 expander I think you want the following since
> > > and64_2_operand covers the extra double-rotate cases, not all DImode.
> > >
> > > - if ((mode == DImode && !and64_2_operand (operands[2],
> > > mode))
> > > - || (mo
On Mon, Jun 01, 2015 at 08:39:05AM -0500, Segher Boessenkool wrote:
> On Mon, Jun 01, 2015 at 11:33:18AM +0930, Alan Modra wrote:
> > Unifying andsi_mask with anddi_mask, and the fact that constraints for
> > const_int see VOIDmode rather than the operand mode is why we get
> > rldicr rather than r
On Mon, Jun 01, 2015 at 11:33:18AM +0930, Alan Modra wrote:
> Unifying andsi_mask with anddi_mask, and the fact that constraints for
> const_int see VOIDmode rather than the operand mode is why we get
> rldicr rather than rlwinm. Easily fixed by separating the si/di
> patterns, and with a little m
On Sat, May 30, 2015 at 08:02:20AM -0500, Segher Boessenkool wrote:
> On Sat, May 30, 2015 at 10:47:27AM +0930, Alan Modra wrote:
> > Huh, that does look like you've destroyed my claim about SImode AND.
>
> Carefully worded :-)
Yes, I wrote it meaning as in refuted an argument, but it also fits
t
On Sat, May 30, 2015 at 10:47:27AM +0930, Alan Modra wrote:
> > > > I think this is too simplistic though. For example, AND with -7 is not
> > > > zero-extended (rlwinm rD,rA,0,31,28 sets the high 32 bits of rD to the
> > > > low
> > > > 32 bits of rA).
> > >
> > > We take some pains in rs6000.m
On Fri, May 29, 2015 at 10:00:04AM -0500, Segher Boessenkool wrote:
> On Fri, May 29, 2015 at 11:20:08PM +0930, Alan Modra wrote:
> > On Fri, May 29, 2015 at 07:58:38AM -0500, Segher Boessenkool wrote:
> > > On Fri, May 29, 2015 at 12:41:20PM +0930, Alan Modra wrote:
> > > > +/* Describe how rtl op
On Fri, May 29, 2015 at 11:20:08PM +0930, Alan Modra wrote:
> On Fri, May 29, 2015 at 07:58:38AM -0500, Segher Boessenkool wrote:
> > On Fri, May 29, 2015 at 12:41:20PM +0930, Alan Modra wrote:
> > > +/* Describe how rtl operations on registers behave on this target when
> > > + operating on less
On Fri, May 29, 2015 at 07:58:38AM -0500, Segher Boessenkool wrote:
> On Fri, May 29, 2015 at 12:41:20PM +0930, Alan Modra wrote:
> > +/* Describe how rtl operations on registers behave on this target when
> > + operating on less than the entire register. */
> > +#define EXTEND_OP(OP) \
> > + (
On Fri, May 29, 2015 at 12:41:20PM +0930, Alan Modra wrote:
> I'll tell you one of the reasons why they are
> slower, as any decent hardware engineer could probably figure this out
> themselves anyway. The record form instructions are cracked into two
> internal ops, the basic arithmetic/logic op,
On Thu, May 28, 2015 at 02:42:22PM -0500, Segher Boessenkool wrote:
> > That record form andi. is slower on many processors,
>
> Is it? On which processors?
That sort of info is in the IBM confidential processor book4
supplements. So I can't tell you. (I think it is completely crazy to
keep in
On Fri, May 29, 2015 at 12:09:42AM +0930, Alan Modra wrote:
> It's really annoying when you fix a combine bug and get worse code..
Heh. You've been on the receiving end of that a lot lately :-/
> void foo (signed char *p) { if (*p != 0) *p = 1; }
>
> before after
> foo:
On Thu, May 28, 2015 at 11:13 AM, Alan Modra wrote:
> On Thu, May 28, 2015 at 10:47:53AM -0400, David Edelsohn wrote:
>> This seems like a problem with the cost model. Rc instructions are
>> more expensive and should be represented as such in rtx_costs.
>
> The record instructions do have a highe
On Thu, May 28, 2015 at 10:47:53AM -0400, David Edelsohn wrote:
> This seems like a problem with the cost model. Rc instructions are
> more expensive and should be represented as such in rtx_costs.
The record instructions do have a higher cost (8 vs. 4 for normal
insns). If the cost is increaed
On Thu, May 28, 2015 at 10:39 AM, Alan Modra wrote:
> The problem is that the following testcase on powerpc64le now
> generates worse code.
>
> void foo (signed char *p) { if (*p != 0) *p = 1; }
>
> before after
> foo:foo:
> lbz 9,0(3)
It's really annoying when you fix a combine bug and get worse code..
The following was part of a larger patch. What this part does is
simply not throw away useful info about non-zero bits. The upper bits
that "we don't know anything about" are not those indicated by
last_set_mode, because nonzer
17 matches
Mail list logo
