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 sup
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:
>
> (
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")
> {
>
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 t
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 -save-temp
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 instr
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 “k>>32” in which k is 64bits integer, the
> “define_expand” should fail because op2 is 3
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 TARGET_SECONDA
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
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
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
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 ])
>> (con
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.inser
re a way around it?
>
> Roy.
>
> 2010/10/25 Georg Lay :
>> 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 (s
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 (
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}
>>>
>
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 bl
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 d
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/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
>
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 refer
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
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" "")
>>
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
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 i
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 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 const
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 Lay wrote:
>>>> Hi, I just started playing around with named address spaces for avr.
>>>> Besides general space (ram
> int __far __atomic x;
int volatile __far __atomic x;
makes more sense :-)
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
31 matches
Mail list logo
