Paolo Bonzini schrieb:
> On 11/10/2010 11:58 AM, Georg Lay wrote:
>> In the old 3.4.x (private port) I introduced a target hook in combine,
>> just prior to where recog_for_combine gets called. The hook did some
>> canonicalization of rtx and thereby considerably reduced the number of
>> patterns t
Michael Meissner schrieb:
> In particular, go to pages 5-7 of my tutorial (chapter 6) where I talk about
> scratch registers and allocating a new pseudo in split1 which is now always
> run.
Ah great! That's the missing link. The pseudo hatches in split1 from
scratch.
This makes combine even more
On 11/10/2010 11:58 AM, Georg Lay wrote:
In the old 3.4.x (private port) I introduced a target hook in combine,
just prior to where recog_for_combine gets called. The hook did some
canonicalization of rtx and thereby considerably reduced the number of
patterns that would have been necessary witho
On Tue, Nov 02, 2010 at 10:41:49AM +0100, Georg Lay wrote:
> This solution works:
>
> Generating a named insn in andsi3-expander as
>
> (define_insn_and_split "..."
> [(set (match_operand:SI 0 "register_operand" "")
> (and:SI (match_operand:SI 1 "register_operand" "")
>
On 11/02/2010 12:36 PM, Joern Rennecke wrote:
define_insn_and_split is little more than syntactic sugar to avoid
re-typing the same patterns again.
Yes, on the other hand it was introduced as combiner-splitter patterns
fell out of fashion, substantially replaced by what you call combiner
bri
Quoting Paolo Bonzini :
On 11/02/2010 10:41 AM, Georg Lay wrote:
What I do not understand is*why* this works.
The internals "16.16 How to Split Instructions" mention two flavours of insn
splitting: One after reload for the scheduler and one during
combine stage, the
latter just doing single
On 11/02/2010 11:39 AM, Georg Lay wrote:
Paolo Bonzini schrieb:
On 11/02/2010 10:41 AM, Georg Lay wrote:
What I do not understand is*why* this works.
The internals "16.16 How to Split Instructions" mention two flavours
of insn
splitting: One after reload for the scheduler and one during combin
Paolo Bonzini schrieb:
> On 11/02/2010 10:41 AM, Georg Lay wrote:
>> What I do not understand is*why* this works.
>> The internals "16.16 How to Split Instructions" mention two flavours
>> of insn
>> splitting: One after reload for the scheduler and one during combine
>> stage, the
>> latter just
On 11/02/2010 10:41 AM, Georg Lay wrote:
What I do not understand is*why* this works.
The internals "16.16 How to Split Instructions" mention two flavours of insn
splitting: One after reload for the scheduler and one during combine stage, the
latter just doing single_set --> 2 * single_set spli
Paolo Bonzini schrieb:
> On 10/29/2010 06:18 PM, Georg Lay wrote:
>> (define_split
>>[(set (match_operand:SI 0 "register_operand" "")
>> (and:SI (match_operand:SI 1 "register_operand" "")
>> (match_operand:SI 2 "const_int_operand" "")))
>> (clobber (ma
Paolo Bonzini schrieb:
>> I already had to fix IRA and remove the following part of
>> ira-color.c::assign_hard_reg() because it makes assumptions that do
>> not hold for the machine:
>>
>>if (! allocated_hardreg_p[hard_regno]
>> && ira_hard_reg_not_in_set_p (hard_regno, mode, call_us
On 10/29/2010 06:18 PM, Georg Lay wrote:
(define_split
[(set (match_operand:SI 0 "register_operand" "")
(and:SI (match_operand:SI 1 "register_operand" "")
(match_operand:SI 2 "const_int_operand" "")))
(clobber (match_operand:SI 3 "register_operand" ""
Paolo Bonzini schrieb:
> On 10/29/2010 05:08 PM, Georg Lay wrote:
>> As far as I understand the internals, peephole2 matches due to
>> predicates and
>> condition, it does not care for constraints (except for optional
>> match_scratch)
>
> Yes, I was referring as "using constraints in the define_i
On 10/29/2010 05:08 PM, Georg Lay wrote:
As far as I understand the internals, peephole2 matches due to predicates and
condition, it does not care for constraints (except for optional match_scratch)
Yes, I was referring as "using constraints in the define_insn". But
you're dong that as far as
Paolo Bonzini schrieb:
> On 10/28/2010 03:10 PM, Georg Lay wrote:
>> Georg Lay schrieb:
>>
>>> This code is not nice.
>>>
>>> ;; d8 = d4 * d6
>>> ;; d8 = d2
>>> ;; d2 = d8
>>> ;; return d2
>>
>> this should be
>>
>> ;; d2 = d4 * d6
>> ;; d8 = d2
>> ;; d2 = d8
>> ;; return d2
>
> It seems to me tha
On 10/28/2010 03:10 PM, Georg Lay wrote:
Georg Lay schrieb:
This code is not nice.
;; d8 = d4 * d6
;; d8 = d2
;; d2 = d8
;; return d2
this should be
;; d2 = d4 * d6
;; d8 = d2
;; d2 = d8
;; return d2
It seems to me that some of your peepholes should instead be implemented
using constrain
Georg Lay schrieb:
> This code is not nice.
>
> ;; d8 = d4 * d6
> ;; d8 = d2
> ;; d2 = d8
> ;; return d2
this should be
;; d2 = d4 * d6
;; d8 = d2
;; d2 = d8
;; return d2
Georg
Paolo Bonzini schrieb:
> On 10/22/2010 01:16 PM, Georg Lay wrote:
>> I already tried to fix this by introducing a different return-pattern,
>> i.e. a
>> PARALLEL of return and bunch of clobbers of unused regs. That fixes
>> this problem
>> but has many other disadvantages compared to a simple retur
On 10/28/2010 12:24 PM, Georg Lay wrote:
Emitting a bunch of CLOBBERs in epilogue/sibcall_epilogue works also, at least
for the small example above. But using LOCAL_REGNO seems more natural to me and
that does not clutter RTL.
True. It's a pretty elegant solution, and I missed it in my mail (I
Paolo Bonzini schrieb:
> On 10/27/2010 04:30 PM, Georg Lay wrote:
>> The first time it occurs in "exit block uses" is in pro/epilogue:
>>
>> peep2.c.193r.split2:;; exit block uses 2 [d2] 26 [SP] 27 [a11]
>> peep2.c.195r.pro_and_epilogue:;; exit block uses2 [d2] 15
>> [d15] 26 [SP
On 10/22/2010 01:16 PM, Georg Lay wrote:
I already tried to fix this by introducing a different return-pattern, i.e. a
PARALLEL of return and bunch of clobbers of unused regs. That fixes this problem
but has many other disadvantages compared to a simple return.
What were this disadvantages?
Pa
On 10/27/2010 04:30 PM, Georg Lay wrote:
The first time it occurs in "exit block uses" is in pro/epilogue:
peep2.c.193r.split2:;; exit block uses 2 [d2] 26 [SP] 27 [a11]
peep2.c.195r.pro_and_epilogue:;; exit block uses2 [d2] 15 [d15] 26 [SP]
27 [a11]
peep2.c.196r.dse2:;; exit
Paolo Bonzini schrieb:
> On 10/27/2010 12:54 PM, Georg Lay wrote:
reg 26 (Stackpointer) and reg 27 (return address) do not matter here.
The result ist
insn 10 (CALL) CURRENT = FIRST = 0xc008010 = {...,4,15}
>>>
>>> Ok, this looks like a bug somewhere (either in DF or in your b
On 10/27/2010 12:54 PM, Georg Lay wrote:
reg 26 (Stackpointer) and reg 27 (return address) do not matter here.
The result ist
insn 10 (CALL) CURRENT = FIRST = 0xc008010 = {...,4,15}
Ok, this looks like a bug somewhere (either in DF or in your backend).
hmmm. How could the backend introduce
Paolo Bonzini schrieb:
> On 10/26/2010 07:42 PM, Georg Lay wrote:
>> I set a break at the end of df_simulate_one_insn_backwards.
>> CURRENT = *(live->current->bits)
>> FIRST = *(live->first->bits)
>
> Or call debug_bitmap (). :)
>
>> reg 26 (Stackpointer) and reg 27 (return address) do not matt
On 10/26/2010 07:42 PM, Georg Lay wrote:
I set a break at the end of df_simulate_one_insn_backwards.
CURRENT = *(live->current->bits)
FIRST = *(live->first->bits)
Or call debug_bitmap (). :)
reg 26 (Stackpointer) and reg 27 (return address) do not matter here.
The result ist
insn 10 (CALL)
Paolo Bonzini schrieb:
> On 10/25/2010 11:35 AM, Georg Lay wrote:
(insn 22 8 23 2 peep2.c:5 (set (reg:SI 15 d15)
(and:SI (reg:SI 4 d4 [ x ])
(const_int -98305 [0xfffe7fff]))) 143
{*and3_zeroes.insert.{SI}.ic}
(nil))
(insn 23 22 21 2 p
On 10/25/2010 11:35 AM, Georg Lay wrote:
(insn 22 8 23 2 peep2.c:5 (set (reg:SI 15 d15)
(and:SI (reg:SI 4 d4 [ x ])
(const_int -98305 [0xfffe7fff]))) 143
{*and3_zeroes.insert.{SI}.ic}
(nil))
(insn 23 22 21 2 peep2.c:5 (set (reg:SI 15 d15)
(xor:SI (reg:SI
Paolo Bonzini schrieb:
> On 10/22/2010 01:16 PM, Georg Lay wrote:
>> Then the first insn gets split after reload and before peephole2:
>>
>> (insn 22 8 23 2 peep2.c:5 (set (reg:SI 15 d15)
>> (and:SI (reg:SI 4 d4 [ x ])
>> (const_int -98305 [0xfffe7fff]))) 143
>> {*and3_zeroes.
On 10/22/2010 01:16 PM, Georg Lay wrote:
Then the first insn gets split after reload and before peephole2:
(insn 22 8 23 2 peep2.c:5 (set (reg:SI 15 d15)
(and:SI (reg:SI 4 d4 [ x ])
(const_int -98305 [0xfffe7fff]))) 143 {*and3_zeroes.insert.{SI}.ic}
(nil))
(insn 23 22 21 2
Georg Lay writes:
> Unfortunately, not all dead regs are marked as dead.
OK, you have a good example. And my response is: it seems to me that
d15 should be marked as dead. So the question is why that is not
happening. I don't know the answer.
Ian
Ian Lance Taylor schrieb:
> Georg Lay writes:
>
>> Regs that are "naturally" dead because the function ends are not marked as
>> dead,
>> and therefore some optimization opportunities pass by unnoticed, e.g.
>> together
>> with recog.c::peep2_reg_dead_p() et. al.
>
> I don't understand what yo
Georg Lay writes:
> Regs that are "naturally" dead because the function ends are not marked as
> dead,
> and therefore some optimization opportunities pass by unnoticed, e.g. together
> with recog.c::peep2_reg_dead_p() et. al.
I don't understand what you mean. All registers other than the retu
Hi, I just came across an optimization issue in pass peephole2:
Regs that are "naturally" dead because the function ends are not marked as dead,
and therefore some optimization opportunities pass by unnoticed, e.g. together
with recog.c::peep2_reg_dead_p() et. al.
As I could not find a related PR
34 matches
Mail list logo
