I'm really shooting in the dark here, but my guess is that you have a
define_expand for movdi that is not reload safe. You can do this
operation correctly, you just have to reverse the instructions: load
a5 from (a4 + 4) before you load a4 from (a4). See, e.g.,
mips_split_64bit_move in mips.c
On 13 November 2006 12:27, Mohamed Shafi wrote:
(insn 94 91 95 6 (set (reg:SI 12 a4)
(mem/c:SI (reg:SI 12 a4) [0 D.1863+0 S4 A32])) 15 {movsi_load} (nil)
(nil))
(insn 95 94 31 6 (set (reg:SI 13 a5 [orig:12+4 ] [12])
(mem/c:SI (plus:SI (reg:SI 12 a4)
On 13 November 2006 12:37, Dave Korn wrote:
You *must* implement a movdi expander, and it has to be clever enough to
notice when one of the output registers is going to clobber one of the input
operands and emit the two SImode halves of the move in the opposite order.
Take a look at,
First thanks very much for your thoughts
If those two instructions appear for the first time in the .greg dump
file, then they have been created by reload.
Yes they appear for the first time in .greg dump file.
1. What could be the reason for this behavior?
I'm really shooting in the
On 10 November 2006 22:31, 'Rask Ingemann Lambertsen' wrote:
On Fri, Nov 10, 2006 at 07:11:34PM -, Dave Korn wrote:
No, surely you don't want to do that! You really need a movdi pattern -
even more so if there are no natural DImode-sized registers, as gcse can
get terribly confused
On 11/10/06, Mike Stump [EMAIL PROTECTED] wrote:
On Nov 9, 2006, at 6:39 AM, Mohamed Shafi wrote:
When i diff the rtl dumps for programs passing negative value with and
without frame pointer i find changes from file.greg .
A quick glance at the rtl shows that insn 95 tries to use [a4+4] but
Mohamed Shafi [EMAIL PROTECTED] writes:
(insn 94 91 95 6 (set (reg:SI 12 a4)
(mem/c:SI (reg:SI 12 a4) [0 D.1863+0 S4 A32])) 15 {movsi_load} (nil)
(nil))
(insn 95 94 31 6 (set (reg:SI 13 a5 [orig:12+4 ] [12])
(mem/c:SI (plus:SI (reg:SI 12 a4)
(const_int
On Thu, Nov 09, 2006 at 11:52:02AM -0800, Mike Stump wrote:
The way the instructions are numbered suggests that the code went
wrong before this point. You have to read and understand all the
dumps, whether they are right or wrong and why, track down the code
in the compiler that is
On Fri, Nov 10, 2006 at 07:17:29AM -0800, Ian Lance Taylor wrote:
Mohamed Shafi [EMAIL PROTECTED] writes:
1. What could be the reason for this behavior?
I'm really shooting in the dark here, but my guess is that you have a
define_expand for movdi that is not reload safe.
And in case
On 10 November 2006 17:55, Rask Ingemann Lambertsen wrote:
On Fri, Nov 10, 2006 at 07:17:29AM -0800, Ian Lance Taylor wrote:
Mohamed Shafi [EMAIL PROTECTED] writes:
1. What could be the reason for this behavior?
I'm really shooting in the dark here, but my guess is that you have a
On Fri, Nov 10, 2006 at 07:11:34PM -, Dave Korn wrote:
No, surely you don't want to do that! You really need a movdi pattern -
even more so if there are no natural DImode-sized registers, as gcse can get
terribly confused by bad reg_equal notes if you don't. See e.g.:
On 11/7/06, Mike Stump [EMAIL PROTECTED] wrote:
On Nov 6, 2006, at 9:30 PM, Mohamed Shafi wrote:
My target (non gcc/private one) fails for long long testcases
Does it work flawlessly otherwise, if not, fix all those problems
first. After those are all fixed, then you can see if it then just
On Nov 9, 2006, at 6:39 AM, Mohamed Shafi wrote:
When i diff the rtl dumps for programs passing negative value with and
without frame pointer i find changes from file.greg .
And, is that change bad? We do expect changes in codegen, you didn't
say if those changes are invalid, or what was
Thanks for the input and the questions
Did you examine:
long long l, k;
l = -k;
for correctness by itself? Was it valid or invalid?
Yes this is working.
[ read ahead for spoilers, I'd rather you pull this information out
of the dump and present it to us... ]
A quick glance at
Mohamed Shafi [EMAIL PROTECTED] writes:
and one more thing. In the dumps i noticed that before using a
register in DI mode they are all clobbred first, like
(insn 30 54 28 6 (clobber (reg:DI 34)) -1 (nil)
(nil))
What is the use of this insns ... Why do we need to clobber these
Mohamed Shafi [EMAIL PROTECTED] writes:
Looking at a .md file of a backend it there a way to know whether a
target supports long long
gcc always supports long long for all targets.
Can you ask a more precise question?
Ian
On Mon, Nov 06, 2006 at 10:52:00AM +0530, Mohamed Shafi wrote:
Hello all,
Looking at a .md file of a backend it there a way to know whether a
target supports long long
Should i look for patterns with machine mode DI?
No. For example, 8-bit, 16-bit and 32-bit targets should normally not
Thanks for the reply
My target (non gcc/private one) fails for long long testcases and
there are cases (with long long) which gets through, but not with the
right output. When i replace long long with long the testcases runs
fine, even those giving wrong output.
The target is not able to compile
Mohamed Shafi [EMAIL PROTECTED] writes:
So when i looked into the .md file i saw no patterns with DI machine
mode ,used for long long(am i right?), execpt
define_insn adddi3 and define_insn subdi3
The .md file says that this is to prevent gcc from synthesising it,
though i didnt
On Nov 6, 2006, at 9:30 PM, Mohamed Shafi wrote:
My target (non gcc/private one) fails for long long testcases
Does it work flawlessly otherwise, if not, fix all those problems
first. After those are all fixed, then you can see if it then just
works. In particular, you will want to
20 matches
Mail list logo
