[RFT] mem-ref2 branch ready to merge
I am starting a review of the changes I made on the mem-ref2 branch in preparation for a merge to trunk. This is a request for testing. I have personally bootstrapped and tested on x86_64-unknown-linux and powerpc64-linux (both with 32bit multilibs included and for all languages). I also regularly build SPEC CPU 2006 on x86_64, current results are SPEC(R) CINT2006 Summary Estimated Estimated Base Base BasePeak Peak Peak Benchmarks Ref. Run Time Ratio Ref. Run Time Ratio == 400.perlbench9770325 30.1 *9770327 29.8 * 401.bzip29650464 20.8 *9650465 20.8 * 403.gcc 8050290 27.8 *8050290 27.7 * 429.mcf 9120306 29.8 *9120307 29.7 * 445.gobmk 10490421 24.9 * 10490421 24.9 * 456.hmmer9330369 25.3 *9330369 25.3 * 458.sjeng 12100451 26.8 * 12100447 27.1 * 462.libquantum 20720332 62.5 * 20720327 63.4 * 464.h264ref 22130566 39.1 * 22130563 39.3 * 471.omnetpp 6250297 21.0 *6250289 21.6 * 473.astar7020382 18.4 *7020377 18.6 * 483.xalancbmk6900212 32.6 *6900220 31.3 * Est. SPECint(R)_base2006 28.4 Est. SPECint2006 28.4 SPEC(R) CFP2006 Summary Estimated Estimated Base Base BasePeak Peak Peak Benchmarks Ref. Run Time Ratio Ref. Run Time Ratio 410.bwaves 13590336 40.5 * 13590335 40.6 * 416.gamess 19580772 25.4 * 19580770 25.4 * 433.milc 9180387 23.7 *9180388 23.7 * 434.zeusmp 9100357 25.5 *9100358 25.5 * 435.gromacs 7140341 20.9 *7140341 21.0 * 436.cactusADM 11950435 27.5 * 11950436 27.4 * 437.leslie3d 9400316 29.8 *9400315 29.8 * 444.namd 8020412 19.4 *8020413 19.4 * 447.dealII 11440312 36.6 * 11440314 36.4 * 450.soplex 8340218 38.2 *8340217 38.4 * 453.povray 5320192 27.6 *5320186 28.5 * 454.calculix 8250385 21.4 *8250384 21.5 * 459.GemsFDTD10610357 29.8 * 10610356 29.8 * 465.tonto9840390 25.3 *9840388 25.4 * 470.lbm 13740258 53.4 * 13740258 53.2 * 481.wrf 11170367 30.4 * 11170368 30.4 * 482.sphinx3 19490478 40.8 * 19490478 40.8 * Est. SPECfp(R)_base2006 29.3 Est. SPECfp2006 29.3 Measured on an iCore7 with -O3 -ffast-math -funroll-loops -march=core2. No surprises here. As said I am going over the changes, will prepare a changelog and will post interesting pieces for re-review. The branch merge will happen not earlier than next week. Thanks, Richard.
invalid insn generated
Hi,
In my port I get to gen_reload to the lines
/* If IN is a simple operand, use gen_move_insn. */
else if (OBJECT_P (in) || GET_CODE (in) == SUBREG)
{
static int xxx;
xxx = OBJECT_P (in);
tem = emit_insn (gen_move_insn (out, in));
/* IN may contain a LABEL_REF, if so add a REG_LABEL_OPERAND note. */
mark_jump_label (in, tem, 0);
}
the emit_insn which should emit a move insn gets as out a register
from class D and as in the Stack pointer.
In my port there is no insn which can write directly from sp to d. so
the emitted insn is invalid and the compilation terminates.
What might be the problem?
Is it possible to arrive to this point with such arguments and later
to fix it or does the problem begin earlier somewhere.
Thanks, Roy.
question about if_marked construct
Hi,
In the context of bug 31230, I have a question about the if_marked
construct.
[DOC http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html]
if_marked ("expression")
Suppose you want some kinds of object to be unique, and so you
put them in a hash table. If garbage collection marks the hash table,
these objects will never be freed, even if the last other reference
to them goes away. GGC has special handling to deal with this: if you
use the if_marked option on a global hash table, GGC will call the
routine whose name is the parameter to the option on each hash table
entry. If the routine returns nonzero, the hash table entry will be
marked as usual. If the routine returns zero, the hash table entry
will be deleted.
The routine ggc_marked_p can be used to determine if an element has
been marked already; in fact, the usual case is to use if_marked
("ggc_marked_p").
[/DOC]
Suppose we have a tree for type A and a tree for type B called A and
B for short, with both A and B having entries in the type_hash_table
called EA and EB, and as complication that A references B.
Suppose also that we have the following function type_hash_marked_p()
as the if_marked function:
...
static int prop(const_tree type)
{
return type == A;
}
static int type_hash_marked_p (const void *p) {
const_tree const type = ((const struct type_hash *) p)->type;
return ggc_marked_p (type) || prop (type);
}
...
During ggc_mark_roots(), when A and B are not live, 2 scenarios can
happen:
I.
- A and B are not marked
- EA is visited, and since prop(A) holds, EA is marked, then A, then B
- EB is visited, an since B is marked, it is not deleted
II.
- A and B are not marked
- EB is visited, and since prop(B) does not hold, EB is deleted
- EA is visited, an since prop(A) holds, EA is marked, then A, then B
The problem is that depending on the order in which we visit the hash
table entries EB is either marked or deleted.
I see 2 possible approaches to make the behavior predictable:
1. prop() needs to be transitively closed, in other words, prop(A)
and A references B needs to imply prop(B)
2. the garbage collector needs to calculate the transitive closure of
prop(), before deleting any hash table entries.
Approach 1 seems error-prone to me, but that does seem to be the de-
facto choice right now.
Can somebody please comment?
Regards
Tom
PowerPC64, optimization too aggressive?
On Tue, Jun 08, 2010 at 10:27:03PM +0930, Alan Modra wrote: > PowerPC64 gcc support for a larger TOC via -mcmodel option. [snip] I'm having second thoughts about the optimization I added to PowerPC64 gcc with the patch hunk below. Its effect is to use a more efficient TOC/GOT pointer relative address calculation on references known to be local, rather than loading an address out of the TOC/GOT. ie. addis rx,2,s...@toc@ha addi ry,rx,s...@toc@l instead of addis rx,2,s...@got@ha ld ry,s...@got@l(rx) This saves a word in the TOC/GOT and is a little faster too. However, there is a problem: If people build PowerPC64 shared libraries without -fpic/-fPIC then gcc will emit code that requires text relocs to properly support ELF shared library semantics, and I don't intend to change ld and ld.so to do that. It may be better to not do this optimization in gcc at all, especially since we can do the same transformation in ld. This would mean PowerPC64 gcc would lose -mcmodel=medium, retaining -mcmodel=small and -mcmodel=large. If there are no dissenting opinions I'll prepare a gcc patch to do that. > + || (TARGET_CMODEL == CMODEL_MEDIUM > + && GET_CODE (operands[1]) == SYMBOL_REF > + && !CONSTANT_POOL_ADDRESS_P (operands[1]) > + && SYMBOL_REF_LOCAL_P (operands[1]) > + && offsettable_ok_by_alignment (SYMBOL_REF_DECL (operands[1] -- Alan Modra Australia Development Lab, IBM
Re: invalid insn generated
roy rosen writes:
> In my port I get to gen_reload to the lines
>
> /* If IN is a simple operand, use gen_move_insn. */
> else if (OBJECT_P (in) || GET_CODE (in) == SUBREG)
> {
> static int xxx;
> xxx = OBJECT_P (in);
> tem = emit_insn (gen_move_insn (out, in));
> /* IN may contain a LABEL_REF, if so add a REG_LABEL_OPERAND note. */
> mark_jump_label (in, tem, 0);
> }
>
> the emit_insn which should emit a move insn gets as out a register
> from class D and as in the Stack pointer.
> In my port there is no insn which can write directly from sp to d. so
> the emitted insn is invalid and the compilation terminates.
>
> What might be the problem?
> Is it possible to arrive to this point with such arguments and later
> to fix it or does the problem begin earlier somewhere.
This tends to mean that you haven't set REGISTER_MOVE_COST correctly.
You need to make sure that moves between register class D and the
stack pointer have a cost greater than 2. If you are unlucky you may
have to introduce a secondary reload.
Ian
Re: invalid insn generated
roy rosen writes:
> In my port I get to gen_reload to the lines
>
> /* If IN is a simple operand, use gen_move_insn. */
> else if (OBJECT_P (in) || GET_CODE (in) == SUBREG)
> {
> static int xxx;
> xxx = OBJECT_P (in);
> tem = emit_insn (gen_move_insn (out, in));
> /* IN may contain a LABEL_REF, if so add a REG_LABEL_OPERAND note. */
> mark_jump_label (in, tem, 0);
> }
>
> the emit_insn which should emit a move insn gets as out a register
> from class D and as in the Stack pointer.
> In my port there is no insn which can write directly from sp to d. so
> the emitted insn is invalid and the compilation terminates.
>
> What might be the problem?
> Is it possible to arrive to this point with such arguments and later
> to fix it or does the problem begin earlier somewhere.
This tends to mean that you haven't set REGISTER_MOVE_COST correctly.
You need to make sure that moves between register class D and the
stack pointer have a cost greater than 2. If you are unlucky you may
have to introduce a secondary reload.
Ian
Re: question about if_marked construct
Tom de Vries writes:
> static int prop(const_tree type)
> {
> return type == A;
> }
>
> static int type_hash_marked_p (const void *p) {
> const_tree const type = ((const struct type_hash *) p)->type;
> return ggc_marked_p (type) || prop (type);
> }
I would like to question your premise. The gcc garbage collector is
not some general purpose library. It's specifically for the use of
gcc. Why, in gcc, would you want to write such an if_marked property?
Is there some simpler and clearer way to express what you actually
want to have happen?
Ian
Re: patch: honor volatile bitfield types
> Can we similarly promise or say something for accesses of the > containing struct as a whole? I hadn't considered those cases (when would you want to copy a *peripheral* ?) Should be the same as before, I would think.
Re: question about if_marked construct
On Jun 23, 2010, at 16:49, Ian Lance Taylor wrote:
Tom de Vries writes:
static int prop(const_tree type)
{
return type == A;
}
static int type_hash_marked_p (const void *p) {
const_tree const type = ((const struct type_hash *) p)->type;
return ggc_marked_p (type) || prop (type);
}
I would like to question your premise. The gcc garbage collector is
not some general purpose library. It's specifically for the use of
gcc. Why, in gcc, would you want to write such an if_marked property?
Is there some simpler and clearer way to express what you actually
want to have happen?
Ian
Hi Ian,
Thanks for your reaction.
What I am really trying to do, is a bootstrap debug build of 4.3.5.
However, I ran into bug 31230. I minimized the testcase, did an
analysis, created a naive patch to test my hypothesis, tested the
patch and put it in the bug report. Now I'm looking for feedback.
In the question I asked to this mailing list I tried to abstract away
from the specific case I analyzed, to get a more conceptual
discussion about the garbage collector, but maybe that was a mistake,
sorry for the confusion.
My analysis, what I'm trying to get confirmed, is that the the actual
type_hash_marked_p() in gcc is 'such an if_marked property':
...
static int type_hash_marked_p (const void *p) {
tree type = ((struct type_hash *) p)->type;
return ggc_marked_p (type) || TYPE_SYMTAB_POINTER (type);
}
...
Regards
Tom
Re: patch: honor volatile bitfield types
On Wed, Jun 23, 2010 at 11:34:04AM -0400, DJ Delorie wrote: > > > Can we similarly promise or say something for accesses of the > > containing struct as a whole? > > I hadn't considered those cases (when would you want to copy a > *peripheral* ?) Should be the same as before, I would think. Not the peripheral, just one register. e.g. you might read a control register into a struct of the same (32-bit) type, and then read multiple fields from the copied struct. -- Daniel Jacobowitz CodeSourcery
Re: question about if_marked construct
Tom de Vries writes:
> What I am really trying to do, is a bootstrap debug build of 4.3.5.
> However, I ran into bug 31230. I minimized the testcase, did an
> analysis, created a naive patch to test my hypothesis, tested the
> patch and put it in the bug report. Now I'm looking for feedback.
>
> In the question I asked to this mailing list I tried to abstract away
>> From the specific case I analyzed, to get a more conceptual
> discussion about the garbage collector, but maybe that was a mistake,
> sorry for the confusion.
>
> My analysis, what I'm trying to get confirmed, is that the the actual
> type_hash_marked_p() in gcc is 'such an if_marked property':
> ...
> static int type_hash_marked_p (const void *p) {
> tree type = ((struct type_hash *) p)->type;
> return ggc_marked_p (type) || TYPE_SYMTAB_POINTER (type);
> }
Interesting. My first reaction is that this is an invalid use of the
garbage collector. I think there is really only one valid function
that can be used as an if_marked function: one which checks
ggc_marked_p on the structure. The only counterexample I can see in
the current code is this one. It seems to me that we can work around
this by building a separate garbage collector root pointing to all
types for which TYPE_SYMTAB_POINTER is true.
Ian
Re: question about if_marked construct
On Wed, 2010-06-23 at 08:56 -0700, Ian Lance Taylor wrote:
> Tom de Vries writes:
>
> > What I am really trying to do, is a bootstrap debug build of 4.3.5.
> > However, I ran into bug 31230. I minimized the testcase, did an
> > analysis, created a naive patch to test my hypothesis, tested the
> > patch and put it in the bug report. Now I'm looking for feedback.
> >
> > In the question I asked to this mailing list I tried to abstract away
> >> From the specific case I analyzed, to get a more conceptual
> > discussion about the garbage collector, but maybe that was a mistake,
> > sorry for the confusion.
> >
> > My analysis, what I'm trying to get confirmed, is that the the actual
> > type_hash_marked_p() in gcc is 'such an if_marked property':
> > ...
> > static int type_hash_marked_p (const void *p) {
> > tree type = ((struct type_hash *) p)->type;
> > return ggc_marked_p (type) || TYPE_SYMTAB_POINTER (type);
> > }
>
> Interesting. My first reaction is that this is an invalid use of the
> garbage collector. I think there is really only one valid function
> that can be used as an if_marked function: one which checks
> ggc_marked_p on the structure.
A plugin providing its own GC above GGC, like MELT does, also could use
that feature. So don't remove it, please.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
reload question
Hi,
My port supports hardware loops generated by the following (do_end) pattern:
(set (pc) (if_then_else (ne (match_operand:HI 0 "general_register_operand" "d")
(const_int 0))
(label_ref (match_operand 1 "" ""))
(pc)))
(set (match_operand:HI 2 "general_register_operand" "=0")
(plus:HI (match_operand:HI 3 "general_register_operand" "0")
(const_int -1)))
(clobber (match_operand:BI 4 "predicate_register_operand" "=j"))
When Im compiling a loop with high register pressure the register allocator
does not allocate a register for the loop counter (i.e., operand 0) as it has a
long life range. Thus operand 0 has to be reloaded but then I get a failure in
the reload:
error: unable to generate reloads for:
(jump_insn 211 182 188 11 lib5.c:51 (parallel [
(set (pc)
(if_then_else (ne (reg:HI 292 [ N ])
(const_int 0 [0x0]))
(label_ref 183)
(pc)))
(set (reg:HI 292 [ N ])
(plus:HI (reg:HI 292 [ N ])
(const_int -1 [0x])))
(clobber (reg:BI 33 p1 [293]))
]) 506 {do_endhi} (expr_list:REG_UNUSED (reg:BI 33 p1 [293])
(expr_list:REG_BR_PROB (const_int 9100 [0x238c])
(nil)))
-> 183)
lib5.c:105:1: internal compiler error: in find_reloads, at reload.c:3821
Can anybody give me a hint?
I am aware of the following msg:
http://gcc.gnu.org/ml/gcc/2001-09/msg00942.html
but still dont know how to make reload do the work.
thanks,
Alex
Re: reload question
On 06/23/10 11:22, Alex Turjan wrote:
Hi,
My port supports hardware loops generated by the following (do_end) pattern:
(set (pc) (if_then_else (ne (match_operand:HI 0 "general_register_operand" "d")
(const_int 0))
(label_ref (match_operand 1 "" ""))
(pc)))
(set (match_operand:HI 2 "general_register_operand" "=0")
(plus:HI (match_operand:HI 3 "general_register_operand" "0")
(const_int -1)))
(clobber (match_operand:BI 4 "predicate_register_operand" "=j"))
When Im compiling a loop with high register pressure the register allocator
does not allocate a register for the loop counter (i.e., operand 0) as it has a
long life range. Thus operand 0 has to be reloaded but then I get a failure in
the reload:
error: unable to generate reloads for:
(jump_insn 211 182 188 11 lib5.c:51 (parallel [
(set (pc)
(if_then_else (ne (reg:HI 292 [ N ])
(const_int 0 [0x0]))
(label_ref 183)
(pc)))
(set (reg:HI 292 [ N ])
(plus:HI (reg:HI 292 [ N ])
(const_int -1 [0x])))
(clobber (reg:BI 33 p1 [293]))
]) 506 {do_endhi} (expr_list:REG_UNUSED (reg:BI 33 p1 [293])
(expr_list:REG_BR_PROB (const_int 9100 [0x238c])
(nil)))
-> 183)
lib5.c:105:1: internal compiler error: in find_reloads, at reload.c:3821
Can anybody give me a hint?
I am aware of the following msg:
http://gcc.gnu.org/ml/gcc/2001-09/msg00942.html
but still dont know how to make reload do the work.
insns which branch are not allowed to have output reloads. You must
support any kind of register as well as memory operands in your insn for
the loop counter.
Jeff
Re: question about if_marked construct
Basile Starynkevitch writes:
> On Wed, 2010-06-23 at 08:56 -0700, Ian Lance Taylor wrote:
>> Tom de Vries writes:
>>
>> > What I am really trying to do, is a bootstrap debug build of 4.3.5.
>> > However, I ran into bug 31230. I minimized the testcase, did an
>> > analysis, created a naive patch to test my hypothesis, tested the
>> > patch and put it in the bug report. Now I'm looking for feedback.
>> >
>> > In the question I asked to this mailing list I tried to abstract away
>> >> From the specific case I analyzed, to get a more conceptual
>> > discussion about the garbage collector, but maybe that was a mistake,
>> > sorry for the confusion.
>> >
>> > My analysis, what I'm trying to get confirmed, is that the the actual
>> > type_hash_marked_p() in gcc is 'such an if_marked property':
>> > ...
>> > static int type_hash_marked_p (const void *p) {
>> > tree type = ((struct type_hash *) p)->type;
>> > return ggc_marked_p (type) || TYPE_SYMTAB_POINTER (type);
>> > }
>>
>> Interesting. My first reaction is that this is an invalid use of the
>> garbage collector. I think there is really only one valid function
>> that can be used as an if_marked function: one which checks
>> ggc_marked_p on the structure.
>
>
> A plugin providing its own GC above GGC, like MELT does, also could use
> that feature. So don't remove it, please.
I'm not proposing removing any feature. I'm stating my belief that
using if_marked with a function which does anything other than test
ggc_marked_p will not work. I don't think it works today, and I don't
think we should put effort into making it work.
Ian
Re: reload question
> insns which branch are not allowed to have output > reloads. You must > support any kind of register as well as memory operands in > your insn for > the loop counter. Thanks for answer but what do you suggest to do, as my architecture done not support HW loops with memory operands? Alex
Re: reload question
On 06/23/10 12:29, Alex Turjan wrote: insns which branch are not allowed to have output reloads. You must support any kind of register as well as memory operands in your insn for the loop counter. Thanks for answer but what do you suggest to do, as my architecture done not support HW loops with memory operands? Emulate it using normal instructions. You can find examples in various other ports. These situations are rare, but for proper operation, you need to support them. Jeff
Re: PowerPC64, optimization too aggressive?
On 06/23/2010 06:03 AM, Alan Modra wrote: > On Tue, Jun 08, 2010 at 10:27:03PM +0930, Alan Modra wrote: >> PowerPC64 gcc support for a larger TOC via -mcmodel option. > [snip] > > I'm having second thoughts about the optimization I added to PowerPC64 > gcc with the patch hunk below. Its effect is to use a more efficient > TOC/GOT pointer relative address calculation on references known to be > local, rather than loading an address out of the TOC/GOT. ie. > > addis rx,2,s...@toc@ha > addi ry,rx,s...@toc@l > > instead of > > addis rx,2,s...@got@ha > ld ry,s...@got@l(rx) > > This saves a word in the TOC/GOT and is a little faster too. However, > there is a problem: If people build PowerPC64 shared libraries > without -fpic/-fPIC then gcc will emit code that requires text relocs > to properly support ELF shared library semantics, and I don't intend > to change ld and ld.so to do that. Given that the x86_64 ld issues hard errors when people forget -fpic building shared libraries, I don't think this is too much of a problem. That said... > It may be better to not do this optimization in gcc at all, especially > since we can do the same transformation in ld. This would mean > PowerPC64 gcc would lose -mcmodel=medium, retaining -mcmodel=small and > -mcmodel=large. If there are no dissenting opinions I'll prepare a > gcc patch to do that. Simplifying the code models that the user sees is a good thing. So long as the assembly is still available for those that want to explicitly schedule the add instead of the ld insn, and it doesn't sound like you're planning to change that at all. r~
Re: patch: honor volatile bitfield types
> Date: Wed, 23 Jun 2010 11:53:31 -0400 > From: Daniel Jacobowitz > On Wed, Jun 23, 2010 at 11:34:04AM -0400, DJ Delorie wrote: > > > Can we similarly promise or say something for accesses of the > > > containing struct as a whole? > > I hadn't considered those cases (when would you want to copy a > > *peripheral* ?) Should be the same as before, I would think. > Not the peripheral, just one register. e.g. you might read a control > register into a struct of the same (32-bit) type, and then read > multiple fields from the copied struct. Exactly. One register with several fields, which you want or must read together, or that you read, change some fields, then write back, if your write-registers have built-in shadowing. It is of course a prerequisite that you know the ABI-mapping for bitfields. (Which as a sidenote happen to be identical for most common targets with the same endianness, given that you fill exactly 32 bits!) brgds, H-P
Re: question about if_marked construct
On Jun 23, 2010, at 19:40, Ian Lance Taylor wrote:
Basile Starynkevitch writes:
On Wed, 2010-06-23 at 08:56 -0700, Ian Lance Taylor wrote:
Tom de Vries writes:
What I am really trying to do, is a bootstrap debug build of 4.3.5.
However, I ran into bug 31230. I minimized the testcase, did an
analysis, created a naive patch to test my hypothesis, tested the
patch and put it in the bug report. Now I'm looking for feedback.
In the question I asked to this mailing list I tried to abstract
away
From the specific case I analyzed, to get a more conceptual
discussion about the garbage collector, but maybe that was a
mistake,
sorry for the confusion.
My analysis, what I'm trying to get confirmed, is that the the
actual
type_hash_marked_p() in gcc is 'such an if_marked property':
...
static int type_hash_marked_p (const void *p) {
tree type = ((struct type_hash *) p)->type;
return ggc_marked_p (type) || TYPE_SYMTAB_POINTER (type);
}
Interesting. My first reaction is that this is an invalid use of
the
garbage collector. I think there is really only one valid function
that can be used as an if_marked function: one which checks
ggc_marked_p on the structure.
A plugin providing its own GC above GGC, like MELT does, also
could use
that feature. So don't remove it, please.
I'm not proposing removing any feature. I'm stating my belief that
using if_marked with a function which does anything other than test
ggc_marked_p will not work. I don't think it works today, and I don't
think we should put effort into making it work.
Ian
Going from your assessment that the current implementation of
type_hash_marked_p() is incorrect, I think that for 4.4, 4.5 and
trunk it's enough just to remove the TYPE_SYMTAB_POINTER from the
clause (-funit-at-a-time is hardcoded and makes sure the types
between functions stay alive). Fixing this by building a separate
garbage collection root as you suggest would only be needed for 4.3
and earlier.
However, my feeling is that the problem does not classify as a
regression, so I suppose we'd only fix it for the trunk anyway. I'll
try to test a patch for the trunk.
Tom
Accessor macros for target-specific types / enum reg_class -> int changes
There are some target-specific types that are embedded in otherwise target-independent types, namely struct machine_function and CUMULATIVE_ARGS (which is the type of the info member of struct incoming_args). For the multi-target configurations as per PR44566 to work, these types have to be encapsulated in a union, and the individual ports need accessor macros to get at their individual fields. That means all targets that use these fields must be changed. There is also the asm_clobbers field in rtl_data, which is of type HARD_REG_SET, and this also has to be changed into a union for safe operation, although in this case it is only target-independent code that needs to use the accessor macro. Would patches to introduce these accessor macros be considered separately, or should I only submit them as part of the big patch for PR44566? (That patch is currently weighting in at 653689 bytes, I need to add some more target code to complete the target coverage for the accessor macros and enum regset -> int changes, that's likely to add a few scores of kilobytes) Likewise, I need to remove 'enum reg_class' from the target hook interface, because this means something different for each target, and with C++ even the width of the type and the position where the information is passed might vary. My approach is to replace enum reg_class in the hook interface with int. Would patches for this be considered separately?
Re: reload question
Quoting Alex Turjan : When Im compiling a loop with high register pressure the register allocator does not allocate a register for the loop counter (i.e., operand 0) as it has a long life range. Thus operand 0 has to be reloaded but then I get a failure in the reload: ... Can anybody give me a hint? Look at the arc[compact] machine description arc-4_4-20090909-branch - it works quite nicely there.
About stack protector
Hi everyone, I'm starting to dig a little bit in what gcc does to protect the stack from overflows and attacks of that kind. I've found some docs and patches, but they aren't really up to date. I thought I could get some diffs for the parts that manage these features, to see exactly what they do and what the changes are between different versions, but I'm finding really hard to see where exactly I should look, since there's a lot of work done in plenty different areas. All this is for a research I'm doing to work on my thesis, and since the subject is security regarding stack and heap based overflows, if there's some protection I'm not aware of, I would really appreciate if someone tells me about it. Can someone give me any pointers in where to look for this kind of information? Documentation, directions on where to look in the source code, anything would be great. Thanks in advance, Tomas
Re: About stack protector
On Jun 23, 2010, at 22:53, Tomás Touceda wrote: > I'm starting to dig a little bit in what gcc does to protect the stack > from overflows and attacks of that kind. I've found some docs and > patches, but they aren't really up to date. I thought I could get some > diffs for the parts that manage these features, to see exactly what > they do and what the changes are between different versions, but I'm > finding really hard to see where exactly I should look, since there's > a lot of work done in plenty different areas. If you use the Ada front end, use -fstack-check and -gnato, you should be pretty safe from any of that. Of course, their always will be ways to shoot yourself in the foot (such as by using unchecked conversions to turn integers into pointers and the like), but it will be hard to accidentally cause any memory overwriting. -Geert
Re: Accessor macros for target-specific types / enum reg_class -> int changes
Joern Rennecke writes: > Would patches to introduce these accessor macros be considered separately, > or should I only submit them as part of the big patch for PR44566? > Would patches for this be considered separately? I would always prefer to see smaller patches. I can't imagine any case when I would prefer to see a big patch if there were any possible way to break it up into independent pieces. Ian
Re: About stack protector
Tomás Touceda writes: > I'm starting to dig a little bit in what gcc does to protect the stack > from overflows and attacks of that kind. I've found some docs and > patches, but they aren't really up to date. See the -fstack-protector and -fstack-check options. Ian
