avr-gcc puts jump tables in section .progmem.gcc_sw_table and assumes that
.text starts at 0, i.e. LPM is on order to read table entries.
This is no more the case if .text starts ata higher address like typically used
with boot loaders.
This patch adds the few instructions to set RAMPZ and
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
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
David Brown schrieb:
On 08/11/10 16:59, Georg Lay wrote:
Richard Guenther schrieb:
On Mon, Nov 8, 2010 at 3:39 PM, Georg Laya...@gjlay.de wrote:
Hi, I just started playing around with named address spaces for avr.
Besides general space (ram), I introduced a second one, __pgm, which
shall
int __far __atomic x;
int volatile __far __atomic x;
makes more sense :-)
Hi, I just started playing around with named address spaces for avr.
Besides general space (ram), I introduced a second one, __pgm, which
shall address program memory where also constants may live. avr is
havard architecture, and both program memory and ram start at address 0.
From this and the
Georg Lay schrieb:
FYI, the code is as expected when I define the addrspaces to be
subsets of each other.
Georg
Richard Guenther schrieb:
On Mon, Nov 8, 2010 at 3:39 PM, Georg Lay a...@gjlay.de wrote:
Hi, I just started playing around with named address spaces for avr.
Besides general space (ram), I introduced a second one, __pgm, which
shall address program memory where also constants may live. avr
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_used_reg_set))
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 (match_operand:SI 3
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 doing
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 that some of your peepholes should
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_insn
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]
27 [a11
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 return.
What
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/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
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 backend).
hmmm. How
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 peep2.c:5 (set (reg:SI 15 d15
.
2010/10/25 Georg Lay a...@gjlay.de:
roy rosen schrieb:
In my port I get to such a situation:
(insn 60 59 61 4 a.c:65 (set (subreg:SI (reg:HI 129 [ __prephitmp_4 ]) 0)
(zero_extract:SI (subreg:SI (reg/v:DI 138 [ v4hi1 ]) 4)
(const_int 16 [0x10])
(const_int
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.insert.{SI
Ian Lance Taylor schrieb:
Georg Lay a...@gjlay.de 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
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,
Phung Nguyen schrieb:
Dear Georg,
Thank you for your help.
I have a problem after I follow your way. When I compile newlib with
the modified (in the way you did in blackfin) way, I got the error
message:
In function fopencookie:newlib/libc/stdio/fopencookie.c: 261: error,
insn does not
Alex Turjan schrieb:
Hi,
I have 3 questions regarding secondary reload:
1.Is it possible to do the secondary reload via 2 intermediary registers?
As far as I can see the insn that implements the secondary reload has to have
3 operands.
reload insns are deprecated. Use
fanqifei schrieb:
Hi all,
I am porting gcc to a microprocessor. There are no 64bits instructions
in it. I added a small logical shift right optimization to the md
file(see below).
For the statement “k32” in which k is 64bits integer, the
“define_expand” should fail because op2 is 32, not
Phung Nguyen schrieb:
Thank you for your reply,
As I know, operand 0 of call is the address of called function;
operand 1 is the number of arguments; operand 2 is the number of args
as registers. Therefore, where is the info passed to call ??? As I
would like to change the target
Phung Nguyen schrieb:
Dear all,
I am porting GCC to a new target. I don't know how to get attribute of
callee of a call.
I defined a new attribute to assign to a function but when writing for
pattern name call or call_value, I don't know how to know if the
callee is assigned the
Hi, when calling gcc with -frecord-gcc-switch the options passed to cc1
will differ depending on if -save-temps is present or not. E.g. if
calling gcc foo.c -I Z -DX=... -UY ...
in the forst case (with -save-temps) options_passed is: -fpreprocessed
foo.i ...
in the second case (without
roy rosen schrieb:
Hi All,
If I don't use a constraint, is it possible that during ira I get a
register which is not acceptable by the predicate?
In my port I have the following to support HW loops:
(define_predicate lc_operand
(match_operand 0 register_operand)
{
unsigned
Uros Bizjak schrieb:
Hello!
During the macroization of x86 RTX patterns, it became clear that
certain patterns can't be macroized due to mode-dependant (const_int
N) RTXes, where the value of X depends on current mode. As an example,
here are two insn patterns from i386/i386.md:
Eggenmüller Bernd schrieb:
Hi,
I've to represent 32 bit immediates to trans late the libgcc2.
The problem is that my assembler only can represent 16 Bit immediates.
How can I implement a workaround for 32 Bit immediates.
libgcc is written in C, so it's likely that you have no proper support
32 matches
Mail list logo
