Re: i370 port
Hi Ulrich.
Good news is that I have now gotten GCC 3.4.6 to recompile
itself with full optimization on. The compilation time on the
(emulated) mainframe is only 2.5 hours as only a single pass
is required. GCC 3.4.6 requires 49 MB to recompile c-common!
I assume with GCC 3.4.6 it is doing global optimization or
something. It was only 20 MB under 3.2.3.
Anyway, I'm still continuing the cleanup, but now have a strong
fallback position. Basically I won't introduce any machine
definition change that causes the self-compile to fail.
;(define_insn ""
; [(set (match_operand:SI 0 "register_operand" "=d")
; (mult:SI (match_operand:SI 1 "register_operand" "0")
;(match_operand:SI 2 "immediate_operand" "K")))]
; ""
; "*
;{
; check_label_emit ();
; mvs_check_page (0, 4, 0);
; return \"MH %0,%H2\";
;}"
; [(set_attr "length" "4")]
;)
The combination of predicates and constraints on this insn is broken.
Before reload, the predicate "immediate_operand" explicitly allows
*any* SImode immediate value. However, during reload, the "K"
constraint accepts only a subset of values.
Is there a way to give a predicate that just says "look at the
constraint"? It seems a bit overkill to add a new predicate
for this one instruction.
As there is no other alternative,
No other alternative for this same pattern, right? There was an
alternative - the pattern that I explictly asked it to use, since
I'd already done the K check in advance.
and the insn supports neither memory nor register
operands, this is impossible for reload to fix up.
Hmmm. I was wondering whether I could put a memory operand
there, if that means it can fix it up regardless. But that would
give it the idea that it can put a fullword there, when a halfword
operand is required, right?
In addition, I don't quite understand how this pattern works in
the first place; MH requires a memory operand, but this pattern
seems to output an immediate value as operand. Is there some
magic going on in your assembler?
%H2 is ...
;; Special formats used for outputting 370 instructions.
;;
;; %H -- Print a signed 16-bit constant.
in the i370.md documentation which can be seen here:
http://gcc.gnu.org/viewcvs/trunk/gcc/config/i370/i370.md?revision=71850&view=markup&pathrev=77215
(there's not a lot of technical changes since then, mainly
because no-one knew how to make them).
If you indeed want to output immediate values here, you should
As opposed to wanting what? All I want is the MH instruction
to be available for use, so that when someone writes x = x * 5,
it doesn't have to organize a register pair.
probably define a new *predicate* that constrains the set of
allowed values even before reload.
Ok, that should be straightforward if that's the best solution.
In the s390 port, we're instead modelling the MH instruction
with a memory operand (this still allows the generic parts of
GCC to push immediate operands into memory, if they are in
range for an HImode operand):
(define_insn "*mulsi3_sign"
[(set (match_operand:SI 0 "register_operand" "=d")
(mult:SI (sign_extend:SI (match_operand:HI 2 "memory_operand" "R"))
(match_operand:SI 1 "register_operand" "0")))]
""
"mh\t%0,%2"
[(set_attr "op_type" "RX")
(set_attr "type" "imul")])
I tried a lot of variations to try to get this to fit into the i370
scheme, but didn't have any luck.
e.g. I managed to make this:
(define_insn ""
[(set (match_operand:SI 0 "register_operand" "=d")
(mult:SI (sign_extend:SI (match_operand:HI 2 "memory_operand" "g"))
(match_operand:SI 1 "register_operand" "0")))]
""
"*
{
check_label_emit ();
mvs_check_page (0, 4, 0);
return \"MH^I%0,%2\";
}"
[(set_attr "length" "4")]
)
produce:
C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I
../include
cfgloopanal.c
cfgloopanal.c: In function `average_num_loop_insns':
cfgloopanal.c:1379: error: unrecognizable insn:
(insn 68 67 71 7 (set (reg:SI 45)
(mult:SI (reg:SI 44 [ .frequency ])
(const_int 1 [0x2710]))) -1 (insn_list 67 (nil))
(expr_list:REG_DEAD (reg:SI 44 [ .frequency ])
(nil)))
This also seems broken. A MULT:DI must have two DImode operands,
it cannot have one DImode and one SImode operand. Also, it is in
fact incorrect that it takes the full DImode first operand; rather,
it only uses the low 32-bit of its first operand as input.
Ok.
In the s390 port we're modelling the real behavior of the instruction
using two explicit SIGN_EXTEND codes:
(define_insn "mulsidi3"
[(set (match_operand:DI 0 "register_operand" "=d,d")
(mult:DI (sign_extend:DI
(match_operand:SI 1 "register_operand" "%0,0"))
(sign_extend:DI
(match_operand:SI 2 "nonimmediate_operand" "d,R"]
Ok. That certainly looks better.
Well, the point of optimization
gcc code debug
hello I was traversing through the source code of GCC using GDB and I understood some of the function the GCC toplev_main() calls but when i came to one particular initialization init_optimization_passes() i was not able to understand the statements if (pass->static_pass_number) pass->todo_flags_start |= TODO_mark_first_instance; *list = pass; pass->static_pass_number = -1; I want to know what is the static_pass_number, what is the value inside it thanking you yours sincerely Anand Raj S Ulle Shivmurthy -- View this message in context: http://www.nabble.com/gcc-code-debug-tp25491558p25491558.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: gcc code debug
anandulle wrote: > hello > > I was traversing through the source code of GCC using GDB > and I understood some of the function the GCC toplev_main() calls but when i > came to one particular initialization init_optimization_passes() i was not > able to understand the statements > > if (pass->static_pass_number) > pass->todo_flags_start |= TODO_mark_first_instance; > *list = pass; > pass->static_pass_number = -1; > > I want to know what is the static_pass_number, what is the value inside it I suggest you take a look at the place where it is defined, which is easily found by "grep static_pass_number gcc/*.h": it's in tree-pass.h, in struct opt_pass. In the GCC sources, most structs and their member variables have explanatory comments in the header file where they are defined. The one on static_pass_number seems fairly self-explanatory to me. cheers, DaveK
Re: i370 port
Paul Edwards wrote:
> > The combination of predicates and constraints on this insn is broken.
> >
> > Before reload, the predicate "immediate_operand" explicitly allows
> > *any* SImode immediate value. However, during reload, the "K"
> > constraint accepts only a subset of values.
>
> Is there a way to give a predicate that just says "look at the
> constraint"?
Not that I'm aware of.
> It seems a bit overkill to add a new predicate
> for this one instruction.
As an alternative to the operand predicate, you might also add
an extra check to the insn condition. For example, something
along the following lines should work:
(define_insn ""
[(set (match_operand:SI 0 "register_operand" "=d")
(mult:SI (match_operand:SI 1 "register_operand" "0")
(match_operand:SI 2 "const_int_operand" "K")))]
"CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K')"
> > As there is no other alternative,
>
> No other alternative for this same pattern, right? There was an
> alternative - the pattern that I explictly asked it to use, since
> I'd already done the K check in advance.
I was using "alternative" in the sense of multi-alternative
constraints within a single insn pattern, yes. Reload will
never switch to use a different insn pattern, it will only
select one of the existing alternatives in the pattern.
> > and the insn supports neither memory nor register
> > operands, this is impossible for reload to fix up.
>
> Hmmm. I was wondering whether I could put a memory operand
> there, if that means it can fix it up regardless. But that would
> give it the idea that it can put a fullword there, when a halfword
> operand is required, right?
Yes, the memory operand would have to be HImode in that case.
> > In addition, I don't quite understand how this pattern works in
> > the first place; MH requires a memory operand, but this pattern
> > seems to output an immediate value as operand. Is there some
> > magic going on in your assembler?
>
> %H2 is ...
>
> ;; Special formats used for outputting 370 instructions.
> ;;
> ;; %H -- Print a signed 16-bit constant.
Yes, it prints an immediate *constant*.
> > If you indeed want to output immediate values here, you should
>
> As opposed to wanting what? All I want is the MH instruction
> to be available for use, so that when someone writes x = x * 5,
> it doesn't have to organize a register pair.
My point was that the MH instruction on an instruction set
architecture level *does not accept* an immediate operand,
but only a memory operand:
MH R1,D2(X2,B2) [RX]
(There is a MULTIPLY HALFWORD IMMEDIATE (MHI) instruction as well,
but I'm assuming you don't want to use it in the i370 port as that
instruction was added later on.)
So the usual way of using MH to multiply by an immediate value
is to place the constant into memory, typically some form of
literal pool. But I see nothing in the i370 port that would
actually do that; instead, you seem to simply output the immediate
value itself into the assembler source.
If this works, it seems that the assembler will under the covers
manage a literal pool. I was simply wondering if this is indeed
what you're relying on ... (In the s390 port, the compiler will
always manage literal pools completely on its own and does never
rely on any assembler magic in that area.)
> e.g. I managed to make this:
>
> (define_insn ""
> [(set (match_operand:SI 0 "register_operand" "=d")
>(mult:SI (sign_extend:SI (match_operand:HI 2 "memory_operand" "g"))
> (match_operand:SI 1 "register_operand" "0")))]
> ""
> "*
> {
> check_label_emit ();
> mvs_check_page (0, 4, 0);
> return \"MH^I%0,%2\";
> }"
>[(set_attr "length" "4")]
> )
>
> produce:
>
> C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors
> -DHAVE_CON
> FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I
> ../include
> cfgloopanal.c
> cfgloopanal.c: In function `average_num_loop_insns':
> cfgloopanal.c:1379: error: unrecognizable insn:
> (insn 68 67 71 7 (set (reg:SI 45)
> (mult:SI (reg:SI 44 [ .frequency ])
> (const_int 1 [0x2710]))) -1 (insn_list 67 (nil))
> (expr_list:REG_DEAD (reg:SI 44 [ .frequency ])
> (nil)))
Well, in this case someone has to push the constant into a literal pool.
You can either do this at expand time by calling force_const_mem, or else
you have to change the predicate to also accept immediates before reload
(then reload will do the force_const_mem for you). (Note that if you in
fact do not manage a literal pool in the compiler today but rely on the
assembler, as discussed above, this whole approach may be difficult.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
gcc-4.5-20090917 is now available
Snapshot gcc-4.5-20090917 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090917/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 151821 You'll find: gcc-4.5-20090917.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20090917.tar.bz2 C front end and core compiler gcc-ada-4.5-20090917.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20090917.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20090917.tar.bz2 C++ front end and runtime gcc-java-4.5-20090917.tar.bz2 Java front end and runtime gcc-objc-4.5-20090917.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20090917.tar.bz2The GCC testsuite Diffs from 4.5-20090910 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: i370 port
> The combination of predicates and constraints on this insn is broken.
>
> Before reload, the predicate "immediate_operand" explicitly allows
> *any* SImode immediate value. However, during reload, the "K"
> constraint accepts only a subset of values.
Is there a way to give a predicate that just says "look at the
constraint"?
Not that I'm aware of.
This below was what I was hoping for ...
It seems a bit overkill to add a new predicate
for this one instruction.
As an alternative to the operand predicate, you might also add
an extra check to the insn condition. For example, something
along the following lines should work:
(define_insn ""
[(set (match_operand:SI 0 "register_operand" "=d")
(mult:SI (match_operand:SI 1 "register_operand" "0")
(match_operand:SI 2 "const_int_operand" "K")))]
"CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K')"
My eyes lit up when I saw that! However, it produced a compiler
error when I tried it. But undeterred, I tried this:
(define_insn ""
[(set (match_operand:SI 0 "register_operand" "=d")
^I(mult:SI (match_operand:SI 1 "register_operand" "0")
^I^I (match_operand:SI 2 "immediate_operand" "K")))]
"(GET_CODE (operands[2]) == CONST_INT
&& REG_P (operands[0])
&& CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K'))"
"*
{
check_label_emit ();
mvs_check_page (0, 4, 0);
return \"MH^I%0,%H2\";
}"
[(set_attr "length" "4")]
)
And it worked (verified by self-compile)! And I relaxed the
constraint on the "M" instruction as well. Those old warnings
are apparently irrelevant now. Thank you sir. :-)
My point was that the MH instruction on an instruction set
architecture level *does not accept* an immediate operand,
but only a memory operand:
MH R1,D2(X2,B2) [RX]
(There is a MULTIPLY HALFWORD IMMEDIATE (MHI) instruction as well,
but I'm assuming you don't want to use it in the i370 port as that
instruction was added later on.)
Oh, I understand now.
So the usual way of using MH to multiply by an immediate value
is to place the constant into memory, typically some form of
literal pool. But I see nothing in the i370 port that would
actually do that; instead, you seem to simply output the immediate
value itself into the assembler source.
Right, with an "=".
If this works, it seems that the assembler will under the covers
manage a literal pool. I was simply wondering if this is indeed
what you're relying on ...
Yes indeed.
And we go to a lot of effort to maintain the length of that literal
pool, so we know when we need to break out into a new page.
That's what this does:
mvs_check_page (0, 4, 0);
Although, as usual, it's broken. Needs to be (0, 4, 2) for the
4-byte instruction followed by the 2 bytes it will use from the
literal pool.
(In the s390 port, the compiler will
always manage literal pools completely on its own and does never
rely on any assembler magic in that area.)
I see. That explains one of the difficulties of trying to get s390
instruction definitions and use them on i370. People keep asking
why I don't "just" use the s390 ones. If only life were that
simple. :-)
Well, in this case someone has to push the constant into a literal pool.
You can either do this at expand time by calling force_const_mem, or else
you have to change the predicate to also accept immediates before reload
(then reload will do the force_const_mem for you). (Note that if you in
fact do not manage a literal pool in the compiler today but rely on the
assembler, as discussed above, this whole approach may be difficult.)
That's putting it mildly. :-)
Anyway, with that out of the way, I'll take a look at the next one.
There's only one bug remaining that I know of, and 3 workarounds
that I would like to reverse out and fix properly.
BFN. Paul.
Is Non-Blocking cache supported in GCC?
Hi all: Recently I found two relative old papers about non-blocking cache, etc. which are : 1) Reducing memory latency via non-blocking and prefetching caches. BY Tien-Fu Chen and Jean-Loup Baer. 2) Data Prefetching:A Cost/Performance Analysis BY Chris Metcalf It seems the hardware facility does have the potential to improve the performance with compiler's assistance(especially instruction scheduling). while on the other hand, lifting ahead load instructions may resulting in increasing register pressure. So I'm thinking : 1, Has anyone from gcc folks done any investigation on this topic yet, or any statistic data based on gcc available? 2, Does GCC(in any release version) supports it in any targets(such as mips 24ke) with this hardware feature? If not currently, does it possible to support it by using target definition macros and functions? Any tips will be highly appreciated, thanks. -- Best Regards.
Re: Is Non-Blocking cache supported in GCC?
"Amker.Cheng" writes: > Recently I found two relative old papers about non-blocking cache, > etc. which are : > > 1) Reducing memory latency via non-blocking and prefetching > caches. BY Tien-Fu Chen and Jean-Loup Baer. > 2) Data Prefetching:A Cost/Performance Analysis BY Chris Metcalf > > It seems the hardware facility does have the potential to improve the > performance with > compiler's assistance(especially instruction scheduling). while on the > other hand, lifting ahead > load instructions may resulting in increasing register pressure. > > So I'm thinking : > 1, Has anyone from gcc folks done any investigation on this topic yet, > or any statistic data based on gcc available? > 2, Does GCC(in any release version) supports it in any targets(such as > mips 24ke) with this hardware feature? > If not currently, does it possible to support it by using target > definition macros and functions? gcc is able to generate prefetches in loops, via the -fprefetch-loop-arrays option. There are various related parameters, prefetch-latency, l1-cache-line-size, etc. I don't know how well this works. To the extent that it does work, it is supported in the MIPS backend, and should work on the MIPS 24ke. Ian
