Re: How to update reg_dead notes

/25/2015 01:54 PM, Georg-Johann Lay wrote: Am 02/24/2015 um 07:33 PM schrieb Kenneth Zadeck: when i suggested that you do a build with all of the checking turned on, i wanted you to this without you new code in it.there is a good possibility that the problem is that your port is generating bad

Re: How to update reg_dead notes

when i suggested that you do a build with all of the checking turned on, i wanted you to this without you new code in it.there is a good possibility that the problem is that your port is generating bad rtl. Also, you should generate a debuggable compiler so that the line numbers have some re

Re: How to update reg_dead notes

It is generally as easy as just adding the problem and calling df_analyze. You tend to get into trouble if the rtl is not good, i.e. there is improper sharing or other violations of the canonical rtl rules. DF does not like improperly shared rtl and it has not been uncommon for port specific

we are starting the wide int merge

please hold off on committing patches for the next couple of hours as we have a very large merge to do. thanks. kenny

merging the wide-int branch

We are now ready to merge the wide-int branch.The branch was broken into small pieces and each of the area maintainers has approved their pieces. The branch has been tested and runs regression free on three 64 bit platforms: x86, ppc, and s390 and on three 32 bit platforms: x86, arm and s

status of wide-int patch.

At this point we have believe that we have addressed all of the concerns that the community has made about the wide-int branch. We have also had each of the sections of the branch approved by the area maintainers. We are awaiting a clean build on the arm and are currently retesting x86-64, s

Re: reviewers for wide int.

On 04/23/2014 04:04 AM, Richard Biener wrote: On Tue, 22 Apr 2014, Mike Stump wrote: On Apr 22, 2014, at 12:48 PM, Kenneth Zadeck wrote: While of course one hopes that there will be no issues with wide-int, a change of this size will have some pain no matter how well we have tested it

Re: reviewers for wide int.

On 04/22/2014 03:37 PM, Richard Biener wrote: On April 22, 2014 9:28:15 PM CEST, Kenneth Zadeck wrote: Richi, David Edelsohn said that I should talk to you about appointing reviewers for wide-int.While I think that it may not be necessary to have any reviewers for wide-int in the long

reviewers for wide int.

Richi, David Edelsohn said that I should talk to you about appointing reviewers for wide-int.While I think that it may not be necessary to have any reviewers for wide-int in the long term, I think that it would be useful to make Richard Sandiford, Mike Stump and myself reviewers at least f

Re: suspect code in fold-const.c

committed as revision 204987. thanks kenny On 11/18/2013 05:38 AM, Richard Biener wrote: On Fri, 15 Nov 2013, Kenneth Zadeck wrote: This patch fixes a number of places where the mode bitsize had been used but the mode precision should have been used. The tree level is somewhat sloppy about

Re: suspect code in fold-const.c

since it does the correct thing if the underlying mode is a partial int mode. This code has been tested on x86-64 with no regressions. Ok to commit? 2013-11-15 Kenneth Zadeck * tree.c (int_fits_type_p): Change GET_MODE_BITSIZE to GET_MODE_PRECISION. * fold-const.c

Re: suspect code in fold-const.c

On 11/15/2013 04:07 AM, Eric Botcazou wrote: this code from fold-const.c starts on line 13811. else if (TREE_INT_CST_HIGH (arg1) == signed_max_hi && TREE_INT_CST_LOW (arg1) == signed_max_lo && TYPE_UNSIGNED (arg1_type) /* We will flip the si

suspect code in fold-const.c

in doing the wide int conversion, i have found the following code on the trunk which seems somewhat suspect: this code from fold-const.c starts on line 13811. else if (TREE_INT_CST_HIGH (arg1) == signed_max_hi && TREE_INT_CST_LOW (arg1) == signed_max_lo && TYP

Re: [wide-int] int_traits

, Richard Sandiford wrote: [off-list] Kenneth Zadeck writes: Richi, Do you want me to back out the patch that changes the rep for unsigned tree-csts? kenny Doesn't look like you're on IRC, so FWIW: richi: just to check, you still want the scratch array to be separat

this code in fold-const.c:fold_single_bit_test looks wrong to me

if (TREE_CODE (inner) == RSHIFT_EXPR && TREE_CODE (TREE_OPERAND (inner, 1)) == INTEGER_CST && TREE_INT_CST_HIGH (TREE_OPERAND (inner, 1)) == 0 && bitnum < TYPE_PRECISION (type) && 0 > compare_tree_int (TREE_OPERAND (inner, 1), bitnum - TYPE_PRECISION (

Re: question about section 10.12

this looks good to me. does your patch also address the vec_concat issue that marc raised? On 01/26/2013 09:59 PM, Hans-Peter Nilsson wrote: From: Kenneth Zadeck Date: Sat, 26 Jan 2013 16:19:40 +0100 the definition of vec_duplicate in section 10.12 seems to restrictive. i have seen examples

question about section 10.12

the definition of vec_duplicate in section 10.12 seems to restrictive. i have seen examples where the "small vector" is really a scalar. Should the doc be "small vector or scalar"? kenny

Re: Fwd: cselib_record_set breaks due to auto_inc_dec

you need to talk to someone with a higher rtl rating than myself. sorry. On 12/20/2012 08:41 AM, Paulo Matos wrote: -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Kenneth Zadeck Sent: 20 December 2012 12:46 To: David Edelsohn; GCC Development

Re: Fwd: cselib_record_set breaks due to auto_inc_dec

if i had to guess what was going on here, and since i do not have the example or even know the platform, i am just guessing, i would say that at some earlier pass, the sub expression in the regnote and the second set in the parallel were the same expression and that someone changed the second s

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

time. kenny On 11/27/2012 05:03 AM, Richard Biener wrote: On Tue, Nov 27, 2012 at 1:06 AM, Kenneth Zadeck wrote: Richard, I spent a good part of the afternoon talking to Mike about this. He is on the c++ standards committee and is a much more seasoned c++ programmer than I am. He convinced

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

I remind you that the purpose of these patches is to solve problems that exist in the current compiler that we have papered over for years. If someone needs wide-ints in some way that is not foreseen then they can change it. kenny On 11/26/2012 11:30 AM, Richard Biener wrote: On Mon, Nov

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

On 11/26/2012 10:03 AM, Richard Biener wrote: On Mon, Nov 5, 2012 at 2:59 PM, Kenneth Zadeck wrote: On 11/04/2012 11:54 AM, Richard Biener wrote: On Thu, Nov 1, 2012 at 2:10 PM, Richard Sandiford wrote: Kenneth Zadeck writes: I would like you to respond to at least point 1 of this email

Re: a question for the c/c++ front end / standards people.

On 11/05/2012 03:37 PM, Joseph S. Myers wrote: On Mon, 5 Nov 2012, Kenneth Zadeck wrote: This switch to doing math within the precision causes many test cases to behave differently. However, I want to know if differently means "incorrectly" or "I have fixed problems that we ha

Re: a question for the c/c++ front end / standards people.

On 11/05/2012 01:08 PM, Ian Lance Taylor wrote: On Mon, Nov 5, 2012 at 10:02 AM, Kenneth Zadeck wrote: The question is why is having a case label of 256 on a unsigned char switch legal? Are you asking why it is valid in the C language? Or are you asking why it is valid in GIMPLE? I guess

a question for the c/c++ front end / standards people.

i have been trying to change the representation of INT_CSTs so that they do not carry around the limitation that they can only represent numbers as large as 2 host_wide_ints (HWI). I have chosen a variable length implementation that uses an array of HWIs that is just large enough to hold the s

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

Jakub and Richi, At this point I have decided to that i am not going to get the rest of the wide-int patches into a stable enough form for this round. The combination of still living without power at my house and some issues that i hit with the front ends has made it impossible to get this fi

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

On 11/04/2012 11:54 AM, Richard Biener wrote: On Thu, Nov 1, 2012 at 2:10 PM, Richard Sandiford wrote: Kenneth Zadeck writes: I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

kenny On 11/01/2012 09:10 AM, Richard Sandiford wrote: Kenneth Zadeck writes: I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of the mode is less than the size of a HWI and once for th

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

On 11/01/2012 09:10 AM, Richard Sandiford wrote: Kenneth Zadeck writes: I would like you to respond to at least point 1 of this email. In it there is code from the rtl level that was written twice, once for the case when the size of the mode is less than the size of a HWI and once for the

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

us to write the same code over and over again. kenny On 10/31/2012 02:19 PM, Kenneth Zadeck wrote: Jakub, it is hard from all of the threads to actually distill what the real issues are here. So let me start from a clean slate and state them simply. Richi has three primary objections

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

Jakub, it is hard from all of the threads to actually distill what the real issues are here. So let me start from a clean slate and state them simply. Richi has three primary objections: 1) that we can do all of this with a templated version of double-int. 2) that we should not be passing in

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

Jelinek wrote: On Wed, Oct 31, 2012 at 10:04:58AM -0400, Kenneth Zadeck wrote: if one looks at where intel is going, they are doing exactly the same thing.The difference is that they like to add the operations one at a time rather than just do a clean implementation like we did. Soon they will

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

level constant propagators that require infinite precision so he is really the person who both should know about this and generate proper tests. kenny On 10/31/2012 09:55 AM, Jakub Jelinek wrote: On Wed, Oct 31, 2012 at 09:44:50AM -0400, Kenneth Zadeck wrote: The tree-vpn uses an infinite

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

wait is because you really do not like the fact these patches get rid of double in and that style of programming and putting off that day serves no one well. kenny On 10/31/2012 05:59 AM, Richard Sandiford wrote: Richard Biener writes: On Tue, Oct 30, 2012 at 10:05 PM, Kenneth Zadeck

Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon

jakub, i am hoping to get the rest of my wide integer conversion posted by nov 5. I am under some adverse conditions here: hurricane sandy hit her pretty badly. my house is hooked up to a small generator, and no one has any power for miles around. So far richi has promised to review them.

possible typo in gcc/java/expr.c at line 1053

this code looks bogus, i think that the "== INTEGER_CST" needs to disappear. kenny tree build_newarray (int atype_value, tree length) { tree type_arg; tree prim_type = decode_newarray_type (atype_value); tree type = build_java_array_type (prim_type, host_integerp (len

Re: ARM/getting rid of superfluous zero extension

David and i have been talking about this for some time. what is needed is a real global optimization algorithm. my leaning is to make do it at the rtl level because that is where everything has been exposed. but it would be a lot easier in ssa form. The first step in my opinion is to ask t

Re: confusion about fma description in section 16.9 of gccint doc.

committed in revision 187494. thanks. On 05/14/2012 08:05 PM, Ian Lance Taylor wrote: Kenneth Zadeck writes: Should i change the section 16.9 doc to indicate that this pattern is only to be used if the machine can do this with a single rounding? Sure. Ian

confusion about fma description in section 16.9 of gccint doc.

Section 16.9 of the current gcc doc is as follows. It implies that the fma pattern should/could be used on a machine that double rounds the multiply add. `fmam4' Multiply operand 2 and operand 1, then add operand 3, storing the result in operand 0. All operands must have mode m. This pa

Re: pr52543

On 03/20/2012 09:40 AM, Ian Lance Taylor wrote: Kenneth Zadeck writes: I think that the question is really bigger than finding the correct line to fix. The problem is, that this code assumes that machines do not have multiword moves or multiword shifts. My machine has both, and i assume

Re: pr52543

wrote: Kenneth Zadeck writes: I have figured out what the root cause of pr52543, but i need some advise as to how to fix it. The bug only happens if the source or destination of the move is a hard register. lower-subreg never breaks up pseudo to pseudo moves that are larger than word mode

pr52543

I have figured out what the root cause of pr52543, but i need some advise as to how to fix it. The bug only happens if the source or destination of the move is a hard register. lower-subreg never breaks up pseudo to pseudo moves that are larger than word mode. According to richard sandiford,

Re: inconsistencies in the documentation regarding side effects with auto inc-dec

i will fix it. kenny On 03/17/2010 07:28 PM, Ramana Radhakrishnan wrote: > Hi Kenneth, > > The documentation of auto-inc-dec still refers to flow and when I > raised this on IRC folks suggested that you might have some > documentation fixes if any, in this area. > > http://gcc.gnu.org/onlinedocs/

Re: Fwd: Register Pressure in Instruction Level Parallelism

David Edelsohn wrote: > -- Forwarded message -- > From: Albert Cohen > Date: Sun, Jun 28, 2009 at 6:25 PM > Subject: Re: Register Pressure in Instruction Level Parallelism > To: Dave Korn > Cc: re...@meinersbur.de, gcc@gcc.gnu.org, Sid Touati > , Frederic Brault > > > Hi all, > >

naked zero_extracts longer than a word.

Would those that know, (or even those that are just generally vocal) be willing to support a change rtl.texi for sign_extract (and by implication, zero_extract) from If @var{loc} is in memory, its mode must be a single-byte integer mode. If @var{loc} is in a register, the mode to use is specified

bitwise dataflow analysis

Silvius, If you want to persue this, you should go back and look at my patches for subreg level dataflow and start hacking from there. It is not a big step to start from that and modify it for bits. If you start from that, it is most likely not much more than a few days work for the analysis p

Re: [lto][RFC] Do not emit hybrid object files

Diego Novillo wrote: > On Fri, Oct 17, 2008 at 20:52, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > > >> Andrew is correct that the reason for putting both lto and final code in >> the same file was to do the least damage to peoples build tools. A >> change fr

Re: [lto][RFC] Do not emit hybrid object files

Andrew Pinski wrote: > On Fri, Oct 17, 2008 at 2:15 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > >> On Fri, Oct 17, 2008 at 16:51, Richard Henderson <[EMAIL PROTECTED]> wrote: >> >> >>> If the version of GCC being used isn't compatible with the version of the IL >>> in the object file, we

Re: lto gimple types and debug info

Paolo Bonzini wrote: Mark Mitchell wrote: For that matter, "print sizeof(X)" should print the same value when debugging optimized code as when debugging unoptimized code, even if the compiler has optimized X away to an empty structure! I disagree. sizeof(X) in the code will return a value as

Re: lto gimple types and debug info

Daniel Berlin wrote: On Sun, Jul 27, 2008 at 3:10 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote: I agree that, at least in principle, it should be possible to emit the debug info (whether the format is DWARF, Stabs, etc.) once. No, you can't. You would at l

Re: lto gimple types and debug info

Daniel Berlin wrote: On Sun, Jul 27, 2008 at 1:18 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: David Edelsohn wrote: I do not expect LTO (or WHOPR) to work on AIX -- at least not without a lot of work on wrappers around the AIX linker. However, I do not understand why enhancing

Re: lto gimple types and debug info

Mark Mitchell wrote: Kenneth Zadeck wrote: 1) Screw the debugging. The motivation behind this option is that not only is it easy, but the reality is that we have changed the program so much that even if we did "fix up the types" so that the matched the generated program, tha

Re: lto gimple types and debug info

Richard Guenther wrote: On Fri, Jul 25, 2008 at 7:01 AM, Chris Lattner <[EMAIL PROTECTED]> wrote: I dunno, this seems like a thing you could better figure out by trying it and seeing where the problems are than by trying to anticipate every single possible problem (not that there should be no

Re: lto gimple types and debug info

Richard Guenther wrote: On Fri, Jul 25, 2008 at 1:47 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Arnaud Charlet wrote: When danny and it wrote the ipa-type-escape pass, mark mitchell was all over us because we assumed that the type system had some semantic meaning. We ended u

Re: lto gimple types and debug info

Arnaud Charlet wrote: When danny and it wrote the ipa-type-escape pass, mark mitchell was all over us because we assumed that the type system had some semantic meaning. We ended up with a pass that generally finds nothing useful. I would very much like to redo that pass once we can mark a typ

Re: lto gimple types and debug info

Arnaud Charlet wrote: I do not know Fortran but from the description above, this is similar in Ada: you cannot freely mix different pointers, and you cannot make a pointer out of any variable, unless variables are marked 'aliased'. This semantic is already expressed today in GCC trees, so I'm not

Re: lto gimple types and debug info

Daniel Berlin wrote: On Thu, Jul 24, 2008 at 2:13 PM, Chris Lattner <[EMAIL PROTECTED]> wrote: On Jul 24, 2008, at 10:16 AM, Kenneth Zadeck wrote: I thought the whole idea of the LTO project was to keep as much language specific type information as late as possible. If you

Re: lto gimple types and debug info

Arnaud Charlet wrote: In this same vein, I am very interested in using the gimple type system as a way to start moving gcc from being a C compiler that accommodates other languages to a compiler that handles different languages on an equal footing. The freedom that C and C++ "enjoy" to basically

Re: lto gimple types and debug info

Chris Lattner wrote: On Jul 24, 2008, at 9:26 AM, Kenneth Zadeck wrote: 3) Generate the debugging for the types late. The problem here is that we want the gimple type system to be stripped of the front end specific information, so any front end specific info that is only necessary for the

lto gimple types and debug info

I have been working on a design for gimple types. The overall plan is to gimplify the types, as we gimplify the executable code. Then we can release the front end types and recover the space. There are difficulties with this plan and most of them have to do with the generation of debug informa

Re: gimple type system

Richard Guenther wrote: On Fri, Jul 18, 2008 at 11:25 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Diego has asked me to look into what would be needed in a gimple type system. This is an issue that has been brought to a head because now it is time to merge types for lto. There are

gimple type system

Diego has asked me to look into what would be needed in a gimple type system. This is an issue that has been brought to a head because now it is time to merge types for lto. There are a lot of questions that need to be answered before designing such a system and i would like to handle them o

Re: [lto] function to DECL associations for WPA repackaging

Diego Novillo wrote: On 2008-06-12, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: I think that if you want to cast this as we need to have a symbol table for the compiler in general then that is fine. Yes, but we only need a symbol table for globals. Temporaries and locals need

Re: [lto] function to DECL associations for WPA repackaging

Diego Novillo wrote: On 2008-06-11, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: my sense is not to associate put this directly in the cgraph but to keep it as a side table that is indexed by something like the cgraph node id. The reason for leaning in this direction is that "w

Re: [lto] function to DECL associations for WPA repackaging

Richard Guenther wrote: On Thu, Jun 12, 2008 at 3:53 AM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote: On Wed, Jun 11, 2008 at 9:13 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Richard Guenther wrote: On Wed, Jun 11, 2008 at 11:33 PM

Re: [lto] function to DECL associations for WPA repackaging

Daniel Berlin wrote: On Wed, Jun 11, 2008 at 9:13 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Richard Guenther wrote: On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wrote: Doug, Yesterday, we spoke briefly about the need to efficiently determin

Re: [lto] function to DECL associations for WPA repackaging

Richard Guenther wrote: On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wrote: Doug, Yesterday, we spoke briefly about the need to efficiently determine the DECL's required by each function. Here's a more detailed overview. During the WPA phase of WHOPR, we will be reading

Re: ln -r and cherry picking.

Cary Coutant wrote: 2) LTO sections need to be able to find "their index" of decls and types. By "their index" I mean the index that each section used to reference the decls and types when the section was generated. Can't you just put an ELF symbol (can be an unnamed local -- could eve

Re: ln -r and cherry picking.

Arnaud Charlet wrote: I want to point out that the current implementation of lto is not compatible with "ln -r", and will need to be modified to support "cherry picking" the function bodies. I assume you mean "ld -r", right ? Arno yes, of course. Dennis Richie's curse: two letter comm

ln -r and cherry picking.

I want to point out that the current implementation of lto is not compatible with "ln -r", and will need to be modified to support "cherry picking" the function bodies. In the current implementation, each lto section (such as what holds a function body or the streamed information from an ipa pass

Re: [whopr] Design/implementation alternatives for the driver and WPA

Ollie Wild wrote: On Wed, Jun 4, 2008 at 9:14 AM, Chris Lattner <[EMAIL PROTECTED] > wrote: 1) start with all code in memory and see how far you can get. It seems that on reasonable developer machines (e.g. 2GB memory) that we can handle C programs on the

Re: [whopr] Design/implementation alternatives for the driver and WPA

Ian Lance Taylor wrote: Kenneth Zadeck <[EMAIL PROTECTED]> writes: I think that one thing that the gcc community should understand is that to a great extent whopr is a google thing. All of the documents are drafted by google people, in meetings that are only open to google people

Re: [whopr] Design/implementation alternatives for the driver and WPA

Diego Novillo wrote: On Tue, Jun 3, 2008 at 22:26, Chris Lattner <[EMAIL PROTECTED]> wrote: and whopr here. Is LTO the mode "normal people" will use, and whopr is the mode where "people with huge clusters" will use? Will LTO/whopr support useful optimization on common multicore machines?

Re: [lto] Streaming out language-specific DECL/TYPEs

Michael Matz wrote: Hi, On Tue, 3 Jun 2008, Diego Novillo wrote: On Tue, Jun 3, 2008 at 04:51, Richard Guenther <[EMAIL PROTECTED]> wrote: You may want to read http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00349.html Thanks. I think I will try to incorporate this in LTO so w

Re: [lto] Streaming out language-specific DECL/TYPEs

Diego Novillo wrote: On Tue, Jun 3, 2008 at 09:28, Jan Hubicka <[EMAIL PROTECTED]> wrote: Sure if it works, we should be lowering the types during gimplification so we don't need to store all this in memory... But C++ FE still use its local data later in stuff like thunks, but we will need t

Re: [lto] Streaming out language-specific DECL/TYPEs

Diego Novillo wrote: In g++.dg/torture/20070621-1.C we are trying to stream out a structure that contains a TEMPLATE_DECL. This currently causes a failure in lto-function-out.c:output_tree because not only TEMPLATE_DECL is C++-specific, we can't even access its fields from lto-function-out.c. T

Re: Redundant malloc in structure optimization? (testsuite/gcc.dg/struct/wo_prof_global_var.c)

); p.0.3 = (struct struct.0_sub.0 *) D.2240; D.2242 = malloc (4000); p.0.4 = (struct struct.0_sub.1 *) D.2242; p = (struct str_t *) D.2215; p.1 = p.0.4; p.0 = p.0.3; -Original Message- From: Olga Golovanevsky [mailto:[EMAIL PROTECTED] Sent: 01 May 2008 13:19 To: Bingfeng Me

Re: IRA for GCC 4.4

Vladimir Makarov wrote: Peter Bergner wrote: On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote: Thanks, Peter. That was clever and email is very enlightening. I have analogous idea for more compact conflict matrix representation. IRA builds allocno live ranges first (they are ran

Re: No rule to make target `df-byte-scan.c' at rev. 134523

Dominique Dhumieres wrote: At revision 134523, bootstraping fails on i686-apple-darwin9 with: ... gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -

Re: improving auto increment expressions detection across basic blocks.

Kenneth Zadeck wrote: Mark Mitchell wrote: Kenneth Zadeck wrote: The majority of the new bugs were places where the rest of the compiler was just not expecting to see auto inc or dec instructions. If you want to take on doing this kind of extension, be prepared for the additional cost

Re: improving auto increment expressions detection across basic blocks.

Mark Mitchell wrote: Kenneth Zadeck wrote: The majority of the new bugs were places where the rest of the compiler was just not expecting to see auto inc or dec instructions. If you want to take on doing this kind of extension, be prepared for the additional cost. Kenny, do you have any

Re: improving auto increment expressions detection across basic blocks.

The auto-increment code was a quick hack based on the code that existed in flow.c. I moved it to a new pass and generalized it quite a bit, but it is at its core, basicly the same local code. The right way to implement this is as a global, or at least loop by loop problem where du or ud chains gu

comments do not match code.

in reorg.c:3155 there is the following code: /* If we reach a CALL which is not calling a const function or the callee pops the arguments, then give up. */ if (CALL_P (our_prev) && (! CONST_OR_PURE_CALL_P (our_prev) || GET_CODE (pat) != SET || GET_CODE (SET_SRC (pat))

Re: [trunk] Addition to subreg section of rtl.text.

Richard Sandiford wrote: Richard Sandiford <[EMAIL PROTECTED]> writes: - A MODE_PARTIAL_INT mode behaves like the corresponding MODE_INT mode. ...except that (as the docs said) an unknown number of bits read as undefined. Richard I would add two things to the section. One is to

Re: [trunk] Addition to subreg section of rtl.text.

Richard Sandiford wrote: Hi Joern, Thanks for the answer, Joern Rennecke <[EMAIL PROTECTED]> writes: Thanks very much for replying to this. We were starting to get worried that no one was going to reply and we would be left out in the cold. kenny 1) Is it possible to have a MODE_PARTI

Re: [trunk] Addition to subreg section of rtl.text.

Jeff, DJ and Richard, Richard Sandiford and I have taken on the task of trying to fully explain subregs in the gcc docs. This is an area where that traditionally has been very confusing to outsiders and even insiders who were not rtl maintainers. As the community of active developers has

Re: API for callgraph and IPA passes for whole program optimization

Jan Hubicka wrote: This looks mostly fine to me. note that i added you to pr35094 since this patch will resolve that issue. I guess that one of the questions that i would have is why not have there be a base structure for the core passmanager fields, and then a union that contains a one of the

Re: birthpoints in rtl.

Jan Hubicka wrote: > Hi, > >> 1) In ssa, the operands of the phis and the renaming contain >> information. The operands are paired with the cfg edges that the >> values come in on. In fud/birthpoints there is no such pairing or >> renaming. For some problems, like conditional constant, thi

Re: birthpoints in rtl.

Richard Sandiford wrote: > "Steven Bosscher" <[EMAIL PROTECTED]> writes: > >> For the location of the extra instructions, I would *not* keep them on >> the side. If you have something special going on, my motto is: "Make >> it explicit". >> > > Going back to something discussed upthread: w

Re: birthpoints in rtl.

Steven Bosscher wrote: > On Tue, Mar 4, 2008 at 7:58 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > >> Both PHIs and birthpoints are merely factoring devices that let you cut >> down the number of UD links. They don't need to be part of the IL, much >> like none of the DF objects are part of

Re: birthpoints in rtl.

Diego Novillo wrote: > What if you treated subregs as total writes (like we do arrays) and > libcalls as clobbering points? Though I guess that may not be > sufficient. > > it is more productive to spend the cycles getting rid of the libcalls rather than figuring out the edge cases. as steven

Re: birthpoints in rtl.

Diego Novillo wrote: > On 2/29/08 7:04 PM, Steven Bosscher wrote: > >> I am not sure what would happen if GCC would start using FUD chains. >> Is it like in SSA that every register is assigned only once? > > But this would only affect the UD chains built by the DF code. My > idea is to build the s

Re: Issues stopping us from removing libcall notes

Steven Bosscher wrote: > Hello, > > Every time someone brings up the idea to remove libcall notes, people > have to think really hard why GCC still has them. It seemed like a > good idea to record and collect these issues in a meta-bug. Thus, see > PR35413. Please open a new bug report (enhanceme

Re: birthpoints in rtl.

Steven Bosscher wrote: > On Thu, Feb 28, 2008 at 2:32 PM, Paolo Bonzini <[EMAIL PROTECTED]> wrote: > >> > Thanks for the quick response. As it turns out, the libcall issue will >> > soon be gone, as bonzini will be deleting them. We have finally >> > overcome that issue. >> >> Not really.

Re: birthpoints in rtl.

Andrew MacLeod wrote: > Kenneth Zadeck wrote: >> >> Birthpoints are not nearly as useful as phi-functions because the >> algorithms that use birthpoints do not generally leave the birthpoints >> in the right places when they are finished. There is a lot of value >

Re: birthpoints in rtl.

on community without knowledge of Reif and Lewis, but i need to check this for sure. Jeff Law wrote: > Kenneth Zadeck wrote: >> jeff, >> >> i posted this earlier today to the gcc mailing list. I was wondering >> what your feelings were on this. I know you had a hand in the

birthpoints in rtl.

I want to start a discussion about some possible changes to the RTL level of GCC. This discussion is motivated by some of the issues raised in bug 26854. We have addressed many of the issues in this bug, but the remaining issue is cost, in both time and space, for the UD and DU chains built by se

Re: API for callgraph and IPA passes for whole program optimization

> > Thanks for the detailed plan. Yes, please add it to the whopr wiki. > The only aspects that are not too clear to me are what exactly do you > plan to do in mainline. > > One idea would be to do all the basic framework during stage 1 and > leave it in mainline. I would suggest doing as much

Re: lto

Jan Hubicka wrote: > Hi, > >> diego and honza >> >> diego asked on irc were we planning to be able to serialize out all of >> the combined declarations. >> My response we could certainly use the machinery that we currently have >> to do this. >> >> However, I believe that Deigo's motivation is s

lto

diego and honza diego asked on irc were we planning to be able to serialize out all of the combined declarations. My response we could certainly use the machinery that we currently have to do this. However, I believe that Deigo's motivation is somewhat flawed, and for that matter the plans in the

  1   2   3   >