ubject: Re: Redundant logical operations left after early splitting
[EMAIL PROTECTED] wrote:
If I understand correctly:
> Prop. of "0" causes simplfy-rtx to create NOP from OR Rx,0
This NOP (deletion?) creates another set of potential uses - as now
the > prior RHS def now passes
What's important here is that reg1 is being set multiple times. You'd
be better off if you can twiddle the splitters to avoid this behavior.
If you need a new pseudo, then get one :-)
I agree with this, but...
Once you do that, local would propagate these things better. That
still leaves t
[EMAIL PROTECTED] wrote:
If I understand correctly:
Prop. of "0" causes simplfy-rtx to create NOP from OR Rx,0
This NOP (deletion?) creates another set of potential uses - as now the
prior RHS def now passes straight thru to a new set of uses - but we
miss those new uses. (which in the testc
Paolo,
As you suggested, I moved the extra fwprop nearer combine, just after
split - but it failed to propagate anything.
The reason is that immediately post split the data flow is reflecting
cross dependencies between Word and subreg U/D. So the USE of just 1
QImode subreg of SImode regis
)
I will try fwprop in a few different spots latter and see what, if any
changes occur.
thanks again
Andy
-Original Message-
From: Paolo Bonzini <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: gcc@gcc.gnu.org
Sent: Thu, 21 Feb 2008 11:04 am
Subject: Re: Redundant logical opera
Putting fwprop after combine is no problem - but is too early - none of
the patterns would be split at that time - preventing byte level
propagations.
Yeah, I meant "after split" actually.
Anyway, the problem is that if the RHS becomes a constant, fwprop does
not propagate the LHS anymore.
lt;[EMAIL PROTECTED]>; GCC Development
Sent: Thu, 21 Feb 2008 1:06 am
Subject: Re: Redundant logical operations left after early splitting
This would indicate that simplify-rtx inside fwprop is removing OR
Rx,0
but not picking up the the additionally revealed forward propagation
oppertunities
I very grateful for your help and wisdom
Testcase and MD Patch attached
unsigned long f (unsigned char *P)
{
unsigned long C;
C = ((unsigned long)P[1] << 24)
| ((unsigned long)P[2] << 16)
| ((unsigned long)P[3] << 8)
| ((unsigned long)P[4] << 0);
return C;
}
Index: avr.md
This would indicate that simplify-rtx inside fwprop is removing OR Rx,0
but not picking up the the additionally revealed forward propagation
oppertunities
This would seem to be an avoidable limitation.
Yes, can you send me your MD patch and a simple testcase? fwprop is
supposed to be "cas
I tried extra fwprop pass and got some very interesting results!
First "caveat" I just cut/pasted extra pass into list - nor worrying
about detail.
NEXT_PASS (pass_rtl_fwprop);
NEXT_PASS (pass_local_alloc);
To show effects here is assembler code dump (which is easier to read
than R
TECTED]; gcc@gcc.gnu.org
Sent: Wed, 20 Feb 2008 3:26 am
Subject: Re: Redundant logical operations left after early splitting
Propagating REG_EQUIV notes across register-register moves would seem
to a obviously simple way to fix this. Thoughts?
I am not sure local-alloc is the best place to
]
Cc: gcc@gcc.gnu.org
Sent: Wed, 20 Feb 2008 2:15 pm
Subject: RE: Redundant logical operations left after early splitting
On 20 February 2008 18:05, [EMAIL PROTECTED] wrote:
But it does seem that the missing piece is effective constant
propagation + simplification after splits and subregs - wh
Yes - the other approach is to lower at RTL expand.
Unfortunately there is no practical way to lower arithmetic and compare
operations. reload can add arithmetic which messes the "carry"
handling attempts. So we end up with mixed higher level and lower level
RTL.
This mixture then causes ot
On 20 February 2008 18:05, [EMAIL PROTECTED] wrote:
> But it does seem that the missing piece is effective constant
> propagation + simplification after splits and subregs - which is
> currently ineffective in local-alloc (or any later pass)
Hmm, more questions: do you use splitters or insns
[EMAIL PROTECTED] wrote:
I still have to try extra fwprop pass to confirm this solves the issue.
But it does seem that the missing piece is effective constant
propagation + simplification after splits and subregs - which is
currently ineffective in local-alloc (or any later pass)
Adding extr
Dave Korn wrote:
On 20 February 2008 16:34, Jeff Law wrote:
Paolo Bonzini wrote:
Is there any particular function or pass that should be dealing with
IOR rx,0 - that I could trace thru and figure out why it does not
like it (or never gets there)?
I would be looking in combine and simplify-rtx
I still have to try extra fwprop pass to confirm this solves the issue.
But it does seem that the missing piece is effective constant
propagation + simplification after splits and subregs - which is
currently ineffective in local-alloc (or any later pass)
Adding extra pass indeed seems a po
On 20 February 2008 16:34, Jeff Law wrote:
> Paolo Bonzini wrote:
>>
Is there any particular function or pass that should be dealing with
IOR rx,0 - that I could trace thru and figure out why it does not
like it (or never gets there)?
>>> I would be looking in combine and simplify-
Paolo Bonzini wrote:
Propagating REG_EQUIV notes across register-register moves would seem
to a obviously simple way to fix this. Thoughts?
I am not sure local-alloc is the best place to address the overall
problem, I doubt it is intended to provide such optimizations.
An additional cse pass
Paolo Bonzini wrote:
Is there any particular function or pass that should be dealing with
IOR rx,0 - that I could trace thru and figure out why it does not
like it (or never gets there)?
I would be looking in combine and simplify-rtx (which is called by
combine). If your splitter triggers af
Propagating REG_EQUIV notes across register-register moves would seem
to a obviously simple way to fix this. Thoughts?
I am not sure local-alloc is the best place to address the overall
problem, I doubt it is intended to provide such optimizations.
An additional cse pass after split would see
As I understand it (perhaps wrongly), actual splitting only occurs
after combine pass (by split1 pass).
Combine has some limited splitting capabilities. For example it can
try to combine 3 insns, which might not match a pattern, but can match
a splitter which generates 2 insns. I don't recall
Is there any particular function or pass that should be dealing with
IOR rx,0 - that I could trace thru and figure out why it does not like
it (or never gets there)?
I would be looking in combine and simplify-rtx (which is called by
combine). If your splitter triggers after combine, then I'm
Dave and Jeff,
Here are more details and I have include testcase, splitter patterns and
RTL dump to show problem in more detail.
The testcase is:
unsigned long f (unsigned char *P)
{
unsigned long C;
C = ((unsigned long)P[1] << 24)
| ((unsigned long)P[2] << 16)
| ((unsigned long)P
RTL dumps for Combine pass and ASMCONS (last one before local-alloc)
COMBINE
;; Function f (f)
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
insn_cost 2: 4
insn_cost 6: 16
insn_cost 7: 12
insn_cost 8: 16
insn_cost 9: 16
insn_cost
[EMAIL PROTECTED] wrote:
Dave and Jeff,
(sorry if you get more than one copy of this email, it's playing up!)
Here are more details and I have include testcase, splitter patterns and
RTL dump to show problem in more detail.
[ ... ]
Can you send the .combine dump as well as the dump for what
After some digging, I can confirm local-alloc.c is creating OR Rx,0
instructions but not simplifying them
local-alloc.c is not the problem - but right now it the only help I'm
getting for post split optimization.
This occurs when source registers are replaced with equivalent constant
using va
Dave and Jeff,
(sorry if you get more than one copy of this email, it's playing up!)
Here are more details and I have include testcase, splitter patterns and
RTL dump to show problem in more detail.
The testcase is:
unsigned long f (unsigned char *P)
{
unsigned long C;
C = ((unsigned
On 19 February 2008 19:26, [EMAIL PROTECTED] wrote:
> The RTL for IOR Rx,0 does use subregs (since I use simplify_gen_subreg
> in splitter.)
Are there any notes on any of these insns?
cheers,
DaveK
--
Can't think of a witty .sigline today
[EMAIL PROTECTED] wrote:
Jeff,
thanks again for suggestions.
As I understand it (perhaps wrongly), actual splitting only occurs after
combine pass (by split1 pass).
Combine has some limited splitting capabilities. For example it can
try to combine 3 insns, which might not match a pattern, bu
dling subregs better?
best regards
Andy
-Original Message-
From: Jeff Law <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: gcc@gcc.gnu.org
Sent: Tue, 19 Feb 2008 2:47 pm
Subject: Re: Redundant logical operations left after early splitting
[EMAIL PROTECTED] wrote:
The RTL for
[EMAIL PROTECTED] wrote:
The RTL for IOR Rx,0 does use subregs (since I use simplify_gen_subreg
in splitter.)
Perhaps I should generate new pseudo QI registers instead before reload?
It's been a long time, but yes, you could look into creating new
registers if you're early into in the optim
ogical operations left after early splitting
[EMAIL PROTECTED] wrote:
> I am stumped and hope someone more skilled can give me some clues
to > solve this problem I have 4.3/4.4 gcc.
> I have created RTL define/splits for AVR port logical operation
(AND,IOR > etc). These split larg
[EMAIL PROTECTED] wrote:
I am stumped and hope someone more skilled can give me some clues to
solve this problem I have 4.3/4.4 gcc.
I have created RTL define/splits for AVR port logical operation (AND,IOR
etc). These split larger mode operations in to QImode operations. I also
created sim
I am stumped and hope someone more skilled can give me some clues to
solve this problem I have 4.3/4.4 gcc.
I have created RTL define/splits for AVR port logical operation
(AND,IOR etc). These split larger mode operations in to QImode
operations. I also created similar splitters for zero_ex
35 matches
Mail list logo
