In my backend GCC generates illegal scheduled code.
After pass sched2, GCC generates:
;;0--> 486 R1=R3<<0x4:IF,ID,AD,RA,EX,WB
;;1--> 487 A0=R1+`buffer':IF,ID,AD,RA,EX,WB
;;2--> 766 R0=abs(R7):IF,ID,
Am 10.06.2010 um 15:27 schrieb Ian Lance Taylor:
> Boris Boesler writes:
>
>> I get an internal compiler error with gcc-4.2.1 and my own back-end
>> when I support conditional execution:
>>
>> ../build/gcc/cc1 -Wall -O1 -o bug.O1.s bug.c
>>
>> bug.c
I get an internal compiler error with gcc-4.2.1 and my own back-end
when I support conditional execution:
../build/gcc/cc1 -Wall -O1 -o bug.O1.s bug.c
bug.c: In function ‘cond_assign_les0’:
bug.c:13: internal compiler error: in elim_reg_cond, at flow.c:3486
The test C file "bug.c" is:
int cond
Hi!
I upgraded from GCC 4.2.1 to GCC 4.3.1. But with this new version I
can't compile any program with my back-end which works with GCC 4.2.1.
I get the following error message:
empty-void.c: In function 'main':
empty-void.c:15: error: unrecognizable insn:
(insn 14 4 15 empty-void.c:14 (pa
Hi!
Am 05.05.2008 um 09:06 schrieb Mohamed Shafi:
But how can i handle instances like this? Should i be doing
insertion
of nops in reorg pass?
FWIW, I had worked on a port for VLIW processor about three years
back
and IIRC we had used the reorg pass for inserting the nops. I think
if yo
Hi!
The following "program" can be compiled without problems.
extern void something(char *s);
char msg[] = "123456";
int main(int argc, char **argv)
{
something(msg);
return 0;
}
But I can't compile it correctly with my backend. The content of msg
is not emitted; there is only the label
Am 03.04.2008 um 16:22 schrieb Mohamed Shafi:
On Thu, Apr 3, 2008 at 7:35 PM, Ian Lance Taylor <[EMAIL PROTECTED]>
wrote:
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
Now imagine that i have 3 patterns : Pattern A with two instructions
in its template, Pattern B and Pattern C with only one
Am 18.03.2008 um 18:47 schrieb Richard Guenther:
On Tue, Mar 18, 2008 at 6:40 PM, Boris Boesler <[EMAIL PROTECTED]> wrote:
Am 18.03.2008 um 16:21 schrieb Jim Wilson:
Boris Boesler wrote:
The following code generators use FOR_EACH_BB[_REVERSE] in the
target machine dependent reor
Am 18.03.2008 um 16:21 schrieb Jim Wilson:
Boris Boesler wrote:
The following code generators use FOR_EACH_BB[_REVERSE] in the
target machine dependent reorg pass:
- bfin
- frv
- ia64
- mt
- s390
The very first thing that ia64_reorg does is
compute_bb_for_insn
Am 17.03.2008 um 17:45 schrieb Jim Wilson:
Boris Boesler wrote:
But some basic blocks seem to point to insns which are not in the
insn-list. I had a short look at dbr_schedule() in reorg.c and the
basic blocks are not updated. Are they evaluated in a later pass?
No. See pass_free_cfg
Hi!
I inspect code after branch delay slot scheduling by dumping the
insn-list to a VCG-file:
for(insn = get_insns(), NULL_RTX != insn; insn = NEXT_INSN(insn))
dump_insn_and_prev_and_next(insn);
FOR_EACH(bb) dump_bb_and_head_and_end(bb)
But some basic blocks seem to point to insns which a
Hi!
For my architecture with 4 branch delay slots I get the following
RTL in my target dependent reorg pass:
(insn 966 361 364 ../src/XXX.c:1666 (sequence [
(jump_insn 362 361 381 ../src/XXX.c:1666 (set (pc)
(if_then_else (ne (reg:CC 49 CONDSEL)
Hi!
I have to insert NOP-instructions into the insn-stream in my back-
end. I do this with something ala emit_insn_after(gen_nop, xyz). This
works so far.
GCC leaves control-flow operations as they are, if it there are no
instructions which can be used to fill the branch delay slots. My
Hi!
Am 09.01.2008 um 23:54 schrieb Ian Lance Taylor:
Boris Boesler <[EMAIL PROTECTED]> writes:
I'm trying to allocate a scratch register: write immediate constant
into scratch register r, write register r into memory
...
What is wrong with the code above?
There is nothing
Hi!
I'm trying to allocate a scratch register: write immediate constant
into scratch register r, write register r into memory
;; write imm into memory
(define_insn_and_split "mov_imm_by_store"
[(set (match_operand:I8I16 0 "memory_operand""=m")
(match_operand:I8I16 1 "immediate_
Am 08.12.2007 um 02:49 schrieb Joseph S. Myers:
On Fri, 7 Dec 2007, Ross Ridge wrote:
Boris Boesler writes:
Ok, so what have I to do to write a back-end where all addresses are
given in bits? Memory is addressed in bits, not bytes. So I set:
#define BITS_PER_UNIT 1
#define UNITS_PER_WORD
Am 12.12.2007 um 16:21 schrieb Ian Lance Taylor:
Boris Boesler <[EMAIL PROTECTED]> writes:
I "implemented" branch delay slots (define_delay) for my
architecture and I use the command line option -fdelayed-branch. But
branch delay slot filling is done just for a few candidat
Am 05.12.2007 um 22:32 schrieb Ian Lance Taylor:
Boris Boesler <[EMAIL PROTECTED]> writes:
I assume that GCC internals assume that memory can be byte (8 bits)
addressed - for historical reasons.
No. gcc internals assume that memory can be addressed in units of
size BITS_PER_UNIT
On 2007-11-27 18:29, Michael Eager wrote:
> Joseph S. Myers wrote:
> > On Tue, 27 Nov 2007, Michael Eager wrote:
> >
> >> I think that there is a pervasive understanding that SImode is
> >> single precision integer, 32-bits long.
> >
> > Only among contributors not considering non-8-bit bytes. SI
19 matches
Mail list logo