On 03/25/10 10:19, Jie Zhang wrote:
On 03/25/2010 11:22 PM, Jeff Law wrote:
I never bothered to implement hoisting which touched hard regs -- I
never thought the cost/benefit analysis made much sense. It's quite a
bit more work to implement and code motion of hard regs is much more
restricted t
On 03/25/2010 11:24 PM, Steven Bosscher wrote:
On Thu, Mar 25, 2010 at 4:03 PM, Jie Zhang wrote:
I just found that the current RTL code hoisting cannot optimize
REG = ...
if (cond)
{
r0 = REG;
}
else
{
r0 = REG;
...
}
to
REG = ...
r0 = REG;
if (cond
On 03/25/2010 11:22 PM, Jeff Law wrote:
On 03/25/10 09:14, Bernd Schmidt wrote:
On 03/25/2010 04:03 PM, Jie Zhang wrote:
I just found that the current RTL code hoisting cannot optimize
REG = ...
if (cond)
{
r0 = REG;
}
else
{
r0 = REG;
...
}
to
REG = ...
r0 = REG;
if (cond
On Thu, Mar 25, 2010 at 4:03 PM, Jie Zhang wrote:
> I just found that the current RTL code hoisting cannot optimize
>
> REG = ...
> if (cond)
> {
> r0 = REG;
>
> }
> else
> {
> r0 = REG;
> ...
> }
>
> to
>
>
> REG =
On 03/25/10 09:14, Bernd Schmidt wrote:
On 03/25/2010 04:03 PM, Jie Zhang wrote:
I just found that the current RTL code hoisting cannot optimize
REG = ...
if (cond)
{
r0 = REG;
}
else
{
r0 = REG;
...
}
to
REG = ...
r0 = REG;
if (cond
On Thu, Mar 25, 2010 at 4:14 PM, Bernd Schmidt wrote:
> On 03/25/2010 04:03 PM, Jie Zhang wrote:
>> I just found that the current RTL code hoisting cannot optimize
>>
>> REG = ...
>> if (cond)
>> {
>> r0 = REG;
>>
>> }
>>
On 03/25/2010 04:03 PM, Jie Zhang wrote:
> I just found that the current RTL code hoisting cannot optimize
>
> REG = ...
> if (cond)
> {
> r0 = REG;
>
> }
> else
> {
> r0 = REG;
> ...
> }
>
> to
>
>
> REG = ...
I just found that the current RTL code hoisting cannot optimize
REG = ...
if (cond)
{
r0 = REG;
}
else
{
r0 = REG;
...
}
to
REG = ...
r0 = REG;
if (cond)
{
}
else
{
...
}
where REG is a pseudo register and r0 is a physical register. I have
Hi, Jeff:
Thanks. I fixed the bug. The problem is in GO_IF_LEGITIMATE_ADDRESS. In
the reload processing, find_reload function will check the operand address
whether it is effective. I traced the function, and found my
GO_IF_LEGITIMATE_ADDRESS macro thought the following address is strict
legit
daniel.tian wrote:
>> Which means that reg 91 was spilled (ie, it did not get a hard register
>> assigned). You can verify this by looking at reg_equiv_mem[91] just
>> before this loop in reload1.c:
>>
>> /* This loop scans the entire function each go-round
>> and repeats until one repetition spill
> Which means that reg 91 was spilled (ie, it did not get a hard register
> assigned). You can verify this by looking at reg_equiv_mem[91] just
> before this loop in reload1.c:
>
> /* This loop scans the entire function each go-round
> and repeats until one repetition spills no additional hard reg
daniel.tian wrote:
>> This looks like a different problem. What pass generates insn 17? What
>> does insn 17 look like in the prior pass? If r14 is your stack/frame
>> pointer, this might point to a problem in how your port interacts with
>> register allocation/reload as reload can replace a pseudo
daniel.tian wrote:
>
>
>
>> This looks like a different problem. What pass generates insn 17? What
>> does insn 17 look like in the prior pass? If r14 is your stack/frame
>> pointer, this might point to a problem in how your port interacts with
>> register allocation/reload as reload can replace
> This looks like a different problem. What pass generates insn 17? What
> does insn 17 look like in the prior pass? If r14 is your stack/frame
> pointer, this might point to a problem in how your port interacts with
> register allocation/reload as reload can replace a pseudo with an
> equivalent m
daniel.tian wrote:
Hi,
I check the MIPS and ARM, both those cc1 files opened in Insight debug tool
contain the mips.md and arm.md file. It is convenient while break point can
be set in it.
My port md file doesn't appear in the insight.
The mips.md and arm.md file end up in the debug info becaus
"daniel.tian" writes:
> I check the MIPS and ARM, both those cc1 files opened in Insight debug tool
> contain the mips.md and arm.md file. It is convenient while break point can
> be set in it.
> My port md file doesn't appear in the insight.
You seem to be asking a question about Insight rather
Hi,
I check the MIPS and ARM, both those cc1 files opened in Insight debug tool
contain the mips.md and arm.md file. It is convenient while break point can
be set in it.
My port md file doesn't appear in the insight.
How can I make it?
___
Best Regards
Hi, Jeff:
> OK. Subregs of MEMs are a little special. In general, you don't want to
> see these at all. I wouldn't necessarily expect this to be a
> PROMOTE_MODE problem.
>
> As others have suggested, find the first pass where you see a (subreg
> (mem)) expression. That will be a big help. Extra c
daniel tian wrote:
>
> it will be called in GO_IF_LEGITIMATE_ADDRESS, and
> LEGITIMIZE_RELOAD_ADDRESS. So like the following unrecognizable RTL
> has gone.
>
I would _strongly_ recommend you initially develop your port without
defining LEGITIMIZE_RELOAD_ADDRESS. Let reload work in the way it was
田晓南 wrote:
> Hello, guys:
> The porting is really a difficult and huge job. So many things I
> don't know or miss result in countless bugs.
>
Definitely true. Though it gets easier the 2nd, 3rd, 4th, time around :-)
>
> Here I encounter some unrecognizable RTL (R0 to R15 are
Hi Dove:
> The docs for PROMOTE_MODE suggest using `word_mode'; it may be that on mips,
> Pmode and word_mode are the same, but they aren't on your machine?
Yes. I think the Pmode and word_mode is the same as MIPS. So I copy
the code in mips.
I just wanna do the operations in WORD mode, and remov
Paolo Bonzini wrote:
> Dave Korn wrote:
>> daniel.tian wrote:
>>
> 2) what pass is producing those subregs?
>>> This is really puzzled me. I just wrote the PROMOTE_MODE like MIPS.
>>> Any advice?
>> Turn on the RTL dump files and see where the subregs first appear?
>
> Yes, that's waht I m
Dave Korn wrote:
> daniel.tian wrote:
>
2) what pass is producing those subregs?
>> This is really puzzled me. I just wrote the PROMOTE_MODE like MIPS.
>
>> Any advice?
>
> Turn on the RTL dump files and see where the subregs first appear?
Yes, that's waht I meant.
Paolo
daniel.tian wrote:
>>> 2) what pass is producing those subregs?
> This is really puzzled me. I just wrote the PROMOTE_MODE like MIPS.
> Any advice?
Turn on the RTL dump files and see where the subregs first appear? My guess
would be reload, but let's find out.
cheers,
DaveK
Hi:
>> 1) does your machine use cc0?
No. In my RISC chip, there is a status register existed, like ARM. But I now
I didn't write any code to support it, as well as absent cc0 register.
>> 2) what pass is producing those subregs?
This is really puzzled me. I just wrote the PROMOTE_MODE like MIP
daniel.tian wrote:
> But I have already defined the PROMOTE_MODE which will convert all the
> QImode, HImode to SImode in computation.
? That's not what the code you posted says:
> PROMOTE_MODE, stolen from mips, is defined in my port:
> #define PROMOTE_MODE(MODE, UNSIGNEDP, TYPE) \
> if
t...@mavrixtech.com.cn
www.mavrixtech.com
发件人: Paul Yuan [mailto:yingbo@gmail.com]
发送时间: 2009年6月19日 22:27
收件人: 田晓南
主题: Re: How to deal with unrecognizable RTL code
Hi Daniel,
You can handle this issue from two points:
1) How these unrecognized RT
田晓南 wrote:
> Hello, guys:
> The porting is really a difficult and huge job. So many things I
> don't know or miss result in countless bugs.
It should not be hard. You have to tell us however why this is
unrecognizable, that is, what would be the "closest" recognizable insn
supported by you
hink
it's a good point.
My RISC chip only accepts the specified RTL which I have already defined
them with insn and expand patterns. So I think there must be a way which
legitimizes RTL code.
(insn:HI 17 13 14 0 (set (mem/s:SI (plus:SI (mem/f:SI (reg/f:SI 14 R14) [15
header+0 S4 A32])
in gcc-3.4.1
rtl can be generated when parsing the source program,
for example,
stmt:
compstmt
{ stmt_count++; $$ = $1; }
| expr ';'
{ stmt_count++;
$$ = c_expand_expr_stmt ($1); }
while in c_expand_body, rtl can also be generated .
what are they respectively
Rajkishore Barik wrote:
Can someone tell me if there is a way to generate RTL code which does not
include use and def of the same pseudo in the same insn?
That depends on how you are generating RTL, but it should be pretty
obvious that you can use gen_reg_rtx to generate a temp reg for use as a
Can someone tell me if there is a way to generate RTL code which does not
include use and def of the same pseudo in the same insn? Of course, I
can break every such instruction into two but I am wondering if it is
already
there or anyone has the code already available.
i.e. generate
t=p56+p76
32 matches
Mail list logo
