On Tue, Aug 21, 2012 at 10:26 AM, Dimitrios Apostolou wrote:
>
> In a very brief summary, I achieved a few things this summer: Ported patches
> from last year - some made it to mainline, extended old patches and
> resubmitted them, wrote new but mostly small clean-ups/speed-ups.k
Thanks for all y
This year's GSOC has come to an end.
In a very brief summary, I achieved a few things this summer: Ported
patches from last year - some made it to mainline, extended old patches
and resubmitted them, wrote new but mostly small clean-ups/speed-ups. In a
nutshell:
[DF] Generate REFs in REGNO o
new job:
*
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Diego
Novillo
Sent: Tuesday, June 15, 2010 4:03 AM
To: gcc@gcc.gnu.org
Subject: [RFC] Cleaning up the pass manager
I have been thinking about doing some cleanups to the pass manager.
The goal wo
Quoting Basile Starynkevitch :
I believe that a structured comment could help. When - in many
years :-( - the powerful people (Steering Committee, FSF, RMS, ...)
would accept the idea of generating documentation from code [and
implement the legalese allowing it thru appropriate exceptions, or le
On 15 June 2010 10:40, Richard Guenther wrote:
> On Tue, Jun 15, 2010 at 4:03 AM, Diego Novillo wrote:
>
>> - Pass scheduling can be done by simply declaring a pass and
>> presenting it to the pass manager. The property sets should be enough
>> for the PM to know where to schedule a pass.
>
> Ug
On Tue, 2010-06-15 at 18:38 +0200, Jan Hubicka wrote:
Citing Diego Novillo:
> > I have been thinking about doing some cleanups to the pass manager.
> This has been my goal for years, but somehow it always got off the top of
> TODO list ;)
> >
> > Additionally, I would like to (at some point) inc
> I have been thinking about doing some cleanups to the pass manager.
> The goal would be to have the pass manager be the central driver of
> every action done by the compiler. In particular, the front ends
> should make use of it and the callgraph manager, instead of the
> twisted interactions we
On Tue, Jun 15, 2010 at 4:03 AM, Diego Novillo wrote:
> I have been thinking about doing some cleanups to the pass manager.
> The goal would be to have the pass manager be the central driver of
> every action done by the compiler. In particular, the front ends
> should make use of it and the call
Quoting Manuel López-Ibáñez :
I would think that instead of hooks, a program should be able to call
pass_manager functions to query/add/remove/reorder passes within a
running program. That is, make the pass_manager a library that works
on passes. GCC would just call that library to implement its
On 15 June 2010 04:03, Diego Novillo wrote:
> I have been thinking about doing some cleanups to the pass manager.
> The goal would be to have the pass manager be the central driver of
> every action done by the compiler. In particular, the front ends
> should make use of it and the callgraph mana
Quoting Diego Novillo :
- Fields properties_required, properties_provided and
properties_destroyed should Mean Something other than asserting
whether they exist.
- Whatever doesn't exist before a pass, needs to be computed.
- Pass scheduling can be done by simply declaring a pass and
presenting
I have been thinking about doing some cleanups to the pass manager.
The goal would be to have the pass manager be the central driver of
every action done by the compiler. In particular, the front ends
should make use of it and the callgraph manager, instead of the
twisted interactions we have now.
://gcc.gnu.org/ml/gcc-patches/2005-11/msg01971.html) but I am not
sure what is the best approach to address it. Cleaning-up those latch
blocks for the propose of restoring the single-basic-block loop should
be helpful in general (and not only in the SMS perspective).
So, we can address this inside
While trying to clean, I noticed that
$ make -k -j6 clean
does:
make[5]: *** [insn-recog.o] Interrupt
make[5]: *** [s-attrtab] Interrupt
make[4]: *** [all-stage1-gcc] Interrupt
make[3]: *** [stage1-bubble] Interrupt
Reaping losing child 0x00383f20 PID 18728
make[2]: *** [all] Interrupt
Removi
> On Fri, Dec 23, 2005 at 11:33:20AM -0800, Janis Johnson wrote:
> > > PS: I'm going to try applying the patch to 3.4 and see if it fixes
> > > tinfo1.C.
> >
> > Meanwhile I'm running a regression hunt for the fix on mainline,
> > which is currently looking between 2005-07-29 and 2005-07-30.
On Fri, Dec 23, 2005 at 11:33:20AM -0800, Janis Johnson wrote:
> > PS: I'm going to try applying the patch to 3.4 and see if it fixes
> > tinfo1.C.
>
> Meanwhile I'm running a regression hunt for the fix on mainline, which
> is currently looking between 2005-07-29 and 2005-07-30. Perhaps that's
>
On Fri, Dec 23, 2005 at 02:27:41PM -0500, Kaveh R. Ghazi wrote:
> > Some more info, the reason hpux only showed one XPASS in 3.4 seems to
> > be that the regexp isn't correct to match the assembler syntax.
> > Patches were installed on mainline but not in 3.4 for mmix and hpux:
> > http://gcc.g
> Some more info, the reason hpux only showed one XPASS in 3.4 seems to
> be that the regexp isn't correct to match the assembler syntax.
> Patches were installed on mainline but not in 3.4 for mmix and hpux:
> http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02513.html
> http://gcc.gnu.org/ml/gcc
> The last diagnostic in 3.4.x I'm getting from g++ is this:
> XPASS: g++.dg/rtti/tinfo1.C scan-assembler _ZTIP9CTemplateIhE:
> XPASS: g++.dg/rtti/tinfo1.C scan-assembler-not .globl[
> \\t]+_ZTIP9CTemplateIhE
> as shown here:
> http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg01262.html
>
The last diagnostic in 3.4.x I'm getting from g++ is this:
XPASS: g++.dg/rtti/tinfo1.C scan-assembler _ZTIP9CTemplateIhE:
XPASS: g++.dg/rtti/tinfo1.C scan-assembler-not .globl[ \\t]+_ZTIP9CTemplateIhE
as shown here:
http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg01262.html
There are three xfails
Bernd Schmidt <[EMAIL PROTECTED]> writes:
> Zack Weinberg wrote:
>> The target macros described in the "Addressing Modes" section of the
>> internals manual are rather badly in need of cleaning up.
>
> What's your status on this - would you mind very mu
Zack Weinberg wrote:
The target macros described in the "Addressing Modes" section of the
internals manual are rather badly in need of cleaning up.
What's your status on this - would you mind very much if I made changes
to those macros now?
Bernd
Ian Lance Taylor writes:
> I think this change is a great idea. I want to point out something
> you probably already noticed: some definitions of
> LEGITIMIZE_RELOAD_ADDRESS rely on the fact that they appear in
> reload.c in the only caller, find_reloads_address. For example, the
> definition i
Zack Weinberg <[EMAIL PROTECTED]> writes:
> So, the plan: Step 1 introduces - one at a time - target hooks
> corresponding to each of the above macros. All callers are changed to
> use the hooks. The default definitions of the hooks invoke the
> existing macros. The hardest part of this is work
Original Message
>From: Zack Weinberg
>Sent: 28 February 2005 20:48
> I think I've addressed all the points you bring up in responses to
> other people. If I missed something, please let me know?
>
> zw
Nope, everything seems sound to me. This is a worthy bit of tidying up,
good luck
I think I've addressed all the points you bring up in responses to
other people. If I missed something, please let me know?
zw
Richard Sandiford <[EMAIL PROTECTED]> writes:
> Zack Weinberg <[EMAIL PROTECTED]> writes:
>> I have worked out a tentative plan for replacing most of these macros
>> with ordinary target hooks, and eliminating REG_OK_STRICT. I propose
>> to change GO_IF_LEGITIMATE_ADDRESS, GO_IF_MODE_DEPENDENT_AD
"Dave Korn" <[EMAIL PROTECTED]> writes:
> I'm basically in agreement with you here, and just want to suggest you can
> avoid an awful lot of code duplication by doing something like
>
> #ifdef REG_OK_STRICT
> #define ${CPU}_IS_STRICT 1
> #else
> #define ${CPU}_IS_STRICT 0
> #endif
This idiom i
Kazu Hirata <[EMAIL PROTECTED]> writes:
> Hi Zack,
>
>> So, the plan: Step 1 introduces - one at a time - target hooks
>> corresponding to each of the above macros. All callers are changed to
>> use the hooks.
...
>> Step 2 is to convert each architecture, one at a time, to make
>> target-hook d
Bernd Schmidt <[EMAIL PROTECTED]> writes:
> Zack Weinberg wrote:
>> I have worked out a tentative plan for replacing most of these
>> macros with ordinary target hooks, and eliminating REG_OK_STRICT.
>
> Are you planning to keep the observed behaviour, or do you want to
> make any enhancements that
Hi Dave,
> I'm basically in agreement with you here, and just want to suggest you can
> avoid an awful lot of code duplication by doing something like
>
> #ifdef REG_OK_STRICT
> #define ${CPU}_IS_STRICT 1
> #else
> #define ${CPU}_IS_STRICT 0
> #endif
Sure. In fact, the FRV port and possible
> Zack Weinberg
>> The target macros described in the "Addressing Modes" section of the
>> internals manual are rather badly in need of cleaning up. I see three
>> primary reasons why this is so:
>
> - Very Nice; and wonder, although somewhat orthogonal, if it would b
Original Message
>From: Hans-Peter Nilsson
>Sent: 28 February 2005 14:30
> On Mon, 28 Feb 2005, Dave Korn wrote:
>> Hmmm, actually, I would say that moving these macro definitions into
>> the cpu.c files is a fairly mechanical and trivial transformation.
>> Given:
>
> WRONG!
>
>> ${
Original Message
>From: gcc-owner On Behalf Of Kazu Hirata
>Sent: 28 February 2005 14:41
> So I would change each macro to an
> architecture-specific function in each architecture first. For
> example, GO_IF_LEGITIMATE_ADDRESS should look like this (taken from
> i386.h):
>
> #ifdef REG_
> Zack Weinberg
> The target macros described in the "Addressing Modes" section of the
> internals manual are rather badly in need of cleaning up. I see three
> primary reasons why this is so:
- Very Nice; and wonder, although somewhat orthogonal, if it would be
simila
Zack Weinberg <[EMAIL PROTECTED]> writes:
> I have worked out a tentative plan for replacing most of these macros
> with ordinary target hooks, and eliminating REG_OK_STRICT. I propose
> to change GO_IF_LEGITIMATE_ADDRESS, GO_IF_MODE_DEPENDENT_ADDRESS,
> LEGITIMIZE_ADDRESS, LEGITIMIZE_RELOAD_ADDRE
Hi Zack,
> So, the plan: Step 1 introduces - one at a time - target hooks
> corresponding to each of the above macros. All callers are changed to
> use the hooks. The default definitions of the hooks invoke the
> existing macros. The hardest part of this is working out exactly what
> their sole
On Mon, 28 Feb 2005, Dave Korn wrote:
> Hmmm, actually, I would say that moving these macro definitions into the
> cpu.c files is a fairly mechanical and trivial transformation. Given:
WRONG!
> ${CPU}.h:
> #define GO_IF_LEGITIMATE_ADDRESS(MODE,X,ADDR) \
> if ( some very hairy conditiona
Original Message
>From: gcc-owner On Behalf Of Zack Weinberg
>Sent: 28 February 2005 02:57
> 1) These are the macros subject to REG_OK_STRICT.
[ ... snip! ... ]
>Also, any macro which uses any of the above macros is perforce
>affected.
>
> 2) Several of these macr
Zack Weinberg wrote:
I have worked out a tentative plan for replacing most of these macros
with ordinary target hooks, and eliminating REG_OK_STRICT. I propose
to change GO_IF_LEGITIMATE_ADDRESS, GO_IF_MODE_DEPENDENT_ADDRESS,
LEGITIMIZE_ADDRESS, LEGITIMIZE_RELOAD_ADDRESS, REG_OK_FOR_BASE_P,
REG_MO
The target macros described in the "Addressing Modes" section of the
internals manual are rather badly in need of cleaning up. I see three
primary reasons why this is so:
1) These are the macros subject to REG_OK_STRICT. For those of you
who have managed so far to avoid finding
41 matches
Mail list logo
