I think that it is time that we in the GCC community took some time to
address the problem of compiling very large functions in a somewhat
systematic manner.
GCC has two competing interests here: it needs to be able to provide
state of the art optimization for modest sized functions and it needs
Richard Guenther wrote:
> On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>> I think that it is time that we in the GCC community took some time to
>> address the problem of compiling very large functions in a somewhat
>> systematic manner.
>>
>> GC
Richard Guenther wrote:
> On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>> Richard Guenther wrote:
>> > On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>> >> I think that it is time that we in the GCC community took some
>> time to
&
Paolo Bonzini wrote:
>
>> While I agree with you, I think that there are so many things we are
>> already trying to address, that this one can wait. I think we've
>> been doing a very good job on large functions too, and I believe that
>> authors of very large functions are just getting not only w
Eric Botcazou wrote:
>> AFAIK not one of the tree optimizers disables itself, but perhaps we
>> should. The obvious candidates would be the ones that require
>> recomputation of alias analysis, and the ones that don't update SSA
>> info on the fly (i.e. require update_ssa, which is a horrible compi
Andrew MacLeod wrote:
> On Sat, 2006-11-04 at 15:17 -0500, Kenneth Zadeck wrote:
>
>> ld.
>>
>
>
>> However, I think that before anyone starts hacking anything, we should
>> come to a consensus on an overall strategy and implement something
>>
I have posted a new wiki intended to help port maintainers with issues
that may arise with the dataflow branch. The new wiki page can be found
at http://gcc.gnu.org/wiki/DataflowPorting.
Thanks,
Kenny
> On Sunday I had accidentally chat about the df infrastructure on
> IIRC. I've got some thoughts which I'd like to share.
>
> I like df infrastructure code from the day one for its clearness.
> Unfortunately users don't see it and probably don't care about it.
> With my point of view the df
Vladimir N. Makarov wrote:
>> Vlad,
>> I think that different people can have different perspectives.
>> You have been working on improving the register allocation for several
>> years, but very little has come of it because the reload
>> infrastructure does not suit itself to being integrated wit
Richard Kenner wrote:
>> Regs_ever_live is the poster child of this. In theory regs_ever_live is
>> easy, it is just the set of hard registers that are used. In practice
>> this is a disaster to keep track of because it was only updated
>> occasionally and its values are "randomly" changed by the
> Hi,
>
> I'mm currently looking at the dataflow branch for m68k mainly because of
> the new auto-inc-dec pass, I worked a bit on the old code in flow.c, but
> considering the new pass, I think it doesn't make much sense to continue
> it.
>
I agree. With high probability the auto inc detectio
Ramana Radhakrishnan wrote:
> Hi ,
>
> I am working on integrating a private port into the Dataflow branch and
> am running into a couple of issues with ICEs in global.c . The ICE is
> at gcc_assert ( REGS_LIVE (i)) at line 534 in global_alloc in
> global.c ..
>
> However because of the way we g
Jan Hubicka wrote:
Hi,
We would like to know if there is some way to find the true and false
branches of a conditional jump in RTL. In the tree CFG, we have two
edge flags for that, EDGE_{TRUE,FALSE}_VALUE, but those flags have no
meaning for the RTL CFG. So our question is, is there some other
> Mark Mitchell wrote:
> >
> > struct A {...};
> > struct B { ...; struct A a; ...; };
> >
> >
> > void f() {
> >B b;
> >g(&b.a);
> > }
> >
> >
> >does the compiler have to assume that "g" may access the parts of
> >"b" outside of "a". If the compiler can see the body of "g" tha
I hope to have my code checked in today.
Look in ipa-reference.c
Kenny
Daniel Berlin wrote:
Most of this can be found in the cgraph nodes. The rest requires
scanning the IL.
Ken Zadeck should have code to do this.
On Wed, 2005-07-06 at 08:32 -0400, Michael Tegtmeyer wrote:
Hello,
Is th
Is this a bug or a feature?
I was wrong, I misread some debugging output.
Sorry,
kenny
Andrew Pinski wrote:
On Jul 11, 2005, at 8:50 AM, Daniel Berlin wrote:
On Mon, 2005-07-11 at 08:40 -0400, Kenneth Zadeck wrote:
Is this a bug or a feature?
Bug.
where is it occurring?
I want to say the C++ front-end since that
I have been trying to cleanup the location where the persistent ipa
information is stored.
The original way that I did this was that I had a field in the var_ann
structure that pointed to the ipa_information.
Now that danny has reorganized the decls, the plan was to just add a
field to the f
Mark Mitchell wrote:
Kenneth Zadeck wrote:
The kludge to handle them is documented in cp/name-lookup.c around
line 670
Ugh.
IMO, the right thing here is that there should be only one
FUNCTION_DECL for a given function, ever, period. Default arguments
are not part of "the function&
the splay tree in question is there as part of the type unification.
This is required because our design for combining modules does not unify
the types and this messes up the type escape analysis.
Because of this, the type name must be the key. However, there is the
possibility that doing so
I will pull a patch together tomorrow. There is currently nothing in
the code for keeping the region stuff up to date as changes are made to
the cfg. For most changes this would not be hard, but for some it is
really hard.
Daniel Berlin wrote:
On Thu, 2005-09-22 at 18:49 -0700, Devang Pate
On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote:
> > http://gcc.gnu.org/projects/lto/lto.pdf
>
> Section 4.2
>
> What is the rationale for using a stack-based representation rather
> than a register-based representation? A infinite register based
> solution would seem to ma
Mark Mitchell <[EMAIL PROTECTED]> writes:
> http://gcc.gnu.org/projects/lto/lto.pdf
>
> Section 4.2 (Executable Representation) describes the GVM as a stack
> machine, and mentions load, store, duplicate, and swap operations.
> But it also discusses having registers which correspond to GIMPLE
> >> Thanks for woking on this. Any specific reason why using the LLVM
> >> bytecode wasn't taken into account?
> >
> > It was.
> > A large number of alternatives were explored, including CIL, the JVM,
> > LLVM, etc.
> >
> >> It is proven to be stable, high-level enough to
> >> perform any kind of
> Specifically, advocates of the recent link-time-optimization proposal
> [1] may claim that exposing all of the information that DWARF captures
> (e.g. about the type system) at link-time is a good thing: it makes it
> easier to do specific high-level optimizations, because all of the
> info
Ian and Honza,
Here is a first draft of the a function to find the set of registers
that are (will) be defined on entry to function. I generated this from
our conversation on chat and by looking around.
This function is necessary in the new version of df because, unlike
flow, we do both for
Ian Lance Taylor wrote:
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
1) Do you believe that this code could be correct?
Well, no.
You do not have to sugar coat it, I can handle the truth.
2) Most of the paragraphs are protected by either reload_completed or
epilogue_com
Ian Lance Taylor wrote:
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
For complete accuracy, there are probably going to be some target
specific registers which need to be handled, unfortunately. For
example, on MIPS, with -mabicalls (which is the default on GNU/Linux),
$25 is l
Steven Bosscher wrote:
Hi,
I can't build the trunk today:
gcc -c -O0 -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I.
-I../../trunk/gcc
Steven, actually the last piece of mail I sent you was a lie.
The bug I fixed is different.
The problem is that between the time that I check my code in an now,
someone changed the representation of BASIC_BLOCK.
lorien:~/gccDFTest/gcc(27) diff basic-block.h ../../gccBaseline/gcc
370c370
<
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
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
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
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
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
please hold off on committing patches for the next couple of hours as we
have a very large merge to do.
thanks.
kenny
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
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
/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
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/
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
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
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
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
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,
>
>
Daniel Berlin wrote:
On Fri, 2006-01-20 at 10:53 +0530, Ranjit Mathew wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Mainline fails to bootstrap for me (revision 110017)
on i686-pc-linux-gnu.
Configured as:
$GCC_SRC_DIR/configure --prefix=$HOME/gcc --enable-languages=c,c++,jav
Andreas Jaeger wrote:
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
Daniel Berlin wrote:
The attached fixes *that*, but this just causes a crash deeper in trying to
free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please
Andreas Jaeger wrote:
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
Daniel Berlin wrote:
The attached fixes *that*, but this just causes a crash deeper in trying to
free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please
Zdenek Dvorak wrote:
Hello,
The attached fixes *that*, but this just causes a crash deeper in trying
to free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please reread the email. The issue is *not* fixed according to
Daniel
Eric Botcazou wrote:
So he updated his tree, saw changes in the middle-end and committed
his without testing.
So Kenny would have had to lauch a new bootstrap, wait for a couple of hours
only to discover that something again changed in-between, and so on?
This is exactly what I did,
i686-pc-linux-gnu.
Kenny
2005-01-20 Kenneth Zadeck <[EMAIL PROTECTED]>
* df-scan.c (problem_SCAN): Added NULL reset function.
(df_scan_reset_blocks): Added code to call reset block function
(df_bb_refs_delete) Fixed comment.
(df_insn_refs_delete): Made tolerant of deleting n
Graham Stott wrote:
Andreas,
FWIW I've had successful bootstrap with these checking flags on
x86_64-unknown-lunux-gnu
Graham
My bootstrap was fine also using x86_64-suse-linux-gnu.
Kenny
Andreas Jaeger wrote:
Andrew Pinski <[EMAIL PROTECTED]> writes:
On Jan 21, 2006, at 1:09 PM, Andreas Jaeger wrote:
On Sat, Jan 21, 2006 at 12:42:24PM -0500, Andrew Pinski wrote:
On Jan 21, 2006, at 12:38 PM, Andreas Jaeger wrote:
I'm still seeing this with current S
Zdenek Dvorak wrote:
Hello,
On Fri, 20 Jan 2006, Zdenek Dvorak wrote:
I propose the following workaround instead, that also restores
bootstrap. It changes the way loop-iv uses df to more conservative one,
that does not seem to cause problems.
That's what I like to see... optio
Steven, Zdenek
1) single_set is built on top of single_set2.
2) single_set_2 uses REG_UNUSED notes.
3) tree-ssa-loop-ivops.c:seq_cost uses single_set.
I can find no indication that rtl dfa is run here to provide the
information for single_set to produce the correct answer.
Inquiring minds want t
Daniel Berlin wrote:
> On Sun, 2006-02-19 at 09:56 -0500, Kenneth Zadeck wrote:
>
>> Steven, Zdenek
>>
>> 1) single_set is built on top of single_set2.
>>
> Yes
>
>> 2) single_set_2 uses REG_UNUSED notes.
>>
> Only if
Steven Bosscher wrote:
> Hi,
>
> While teaching dce.c on the dataflow-branch to delete noop-moves,
> I noticed that most noop moves are produced by reload. It inserts
> duplicate insns for some reloads, postreload turns the duplicate
> reload into a simple reg-reg move (but the lhs and rhs are the
Steven Bosscher wrote:
> On 6/15/06, Joern RENNECKE <[EMAIL PROTECTED]> wrote:
>> In http://gcc.gnu.org/ml/gcc/2006-06/msg00549.html, you wrote:
>>
>> > -ftree-live-range-split splits live ranges on exit from ssa. This is
>> > on by default, and in fact it is more work to NOT split unrelated live
Joern RENNECKE wrote:
> I 've been looking at the problem of converting the struct-equiv code
> to use DEF-USE chains
> instead of global dataflow information, but I have hit a snag.
> We can find local registers as being registers that are defined
> somewhere in the examined (partial) block,
> and
Joern RENNECKE wrote:
> Kenneth Zadeck wrote:
>
>>
>>
>> you can have def-use chains, you can have use-def chains or you can have
>> both.
>> It seems like what you are asking for are use-def chains,
>>
> No, I want to know if there exists a path fro
Joern RENNECKE wrote:
> Kenneth Zadeck wrote:
>
>>
>>
>> The right way to do this is not to build chains but to define your own
>> dataflow problem to do this.
>>
> But wouldn't I need to update the problem solution every time a change
> a bit of
Joern Rennecke wrote:
> In http://gcc.gnu.org/ml/gcc/2006-07/msg00390.html, you write:
>
>> depending on what you are doing, you can update the solution in place.
>> The point of the dataflow talk was not to say that you cannot do
>> anything incremental, it was to say that there are no good GEN
Joern RENNECKE wrote:
> Kenneth Zadeck wrote:
>
>>> I suppose reg-live-at-start / reg-live-at-end information is
>>> actually easier
>>> to maintain during if-conversion that def-use chains.
>> This is true, certainly in theory, a lot less so in practi
Joern RENNECKE wrote:
> Kenneth Zadeck wrote:
>
>> From that description I assumed that you really did care which uses
>> actually reached which other uses. The reaching uses problem tracks
>> each use separately. If this isn't what you need then you are free to
>
Joern RENNECKE wrote:
> Kenneth Zadeck wrote:
>
>>
>>
>> You should do this starting from the dataflow branch. The version of
>> if-cvt there works as I have mentioned in the previous mail and does not
>> use propagate block at all.
>>
>>
Joern RENNECKE wrote:
> Kenneth Zadeck wrote:
>
>> Updating the LR dataflow when splitting a basic block is generally
>> pretty easy. You start from the end of the block and just interpret
>> the uses and defs
>> for each insn.
>>
>>
> This means d
Joern RENNECKE wrote:
> Kenneth Zadeck wrote:
>
>>
>>
>> is it really necessary to do your pass after reg stack. Given that
>> there is no if conversion that runs after regstack what is your point?
>>
>>
> I am talking about cross-jumping after reg
Mark,
I have had some discussions with Honza and Diego about the type
consistency at the gimple level. They told me that Andrew was in the
process of making gimple properly type consistent.
I just wanted to point out how this effects encoding gimple into dwarf.
If the gimple is type consistent,
Richard Guenther wrote:
> On 8/11/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>> Mark,
>>
>> I have had some discussions with Honza and Diego about the type
>> consistency at the gimple level. They told me that Andrew was in the
>> process of making gimple
Richard Guenther wrote:
> On 8/11/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>> Richard Guenther wrote:
>> > On 8/11/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>> >> Mark,
>> >>
>> >> I have had some discussions with Honza and
David Edelsohn wrote:
>> Diego Novillo writes:
>>
>
> Diego> Agreed. This is a good opportunity for us to design a GIMPLE type
> Diego> system. Besides the obvious space savings and cleanliness, it is also
> Diego> needed to remove lang_hooks.types_compatible_p.
>
> And
Nick Clifton wrote:
> Hi Diego,
>
>> Jeff's point about our optimizers is also true. Nick, remember that
>> issue with MIPS optimizations you were discussing with Jeff a few days
>> ago? I didn't follow most of the details, but it involved ivopts and
>> sign issues. Could you send a summary?
>
>
Diego Novillo wrote:
> Kenneth Zadeck wrote on 08/15/06 11:57:
>
>
>> We should be looking at the back end to see where it cannot see what it
>> needs to see rather than trying to stop getting the middle end code into
>> a reasonable form.
>>
>>
>
Chris Lattner wrote:
> On Aug 28, 2006, at 6:57 AM, Kenneth Zadeck wrote:
>
>> This posting is a progress report of my task of encoding and decoding
>> the GIMPLE stream into LTO. Included in this posting is a patch that
>> encodes functions and dumps the result to file
Michael Eager wrote:
> Kenneth Zadeck wrote:
>> This posting is a progress report of my task of encoding and decoding
>> the GIMPLE stream into LTO. Included in this posting is a patch that
>> encodes functions and dumps the result to files.
>
> I have only a limi
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>
>
>> This
>> will be more cumbersome if we have to keep reloading each object
>> file's abbrev table just to tear apart a single function in that .o
>> file. While the abbrev sections average slightly
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>> Even if we decide that we are going to process all of the functions in
>> one file at one time, we still have to have access to the functions that
>> are going to be inlined into the function being compiled. Getting at
>
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>> I am not so concerned with running out of virtual address space than I
>> am about being able to break this up so that it can be done in parallel,
>> on a farm of machines. Otherwise, lto can never be part of anyone's
Daniel Jacobowitz wrote:
> On Thu, Aug 31, 2006 at 04:00:25PM -0700, Mark Mitchell wrote:
>
>> I think this is probably moot, since I believe that Kenny feels DWARF is
>> not suitable for reasons other than the abbreviation table issue, but
>> this is a clever technique.
>>
>
> ... for GI
Daniel Jacobowitz wrote:
> On Fri, Sep 01, 2006 at 09:45:34AM -0400, Kenneth Zadeck wrote:
>
>> Given that Mark, and for that matter no one else, did not really push
>> back, I am pretty much committed not to use dwarf.
>>
>
> Then... what are you going
Diego Novillo wrote:
> Kenneth Zadeck wrote on 08/28/06 09:57:
>
>
>> I have not done this because I do not rule the earth. That was not
>> what I was assigned to do, and I agreed that DWARF3 sounded like a
>> reasonable way to go. Now that I understand the d
Andrew Pinski wrote:
> On Fri, 2006-09-01 at 09:51 -0400, Diego Novillo wrote:
>
>>> +#if STUPID_TYPE_SYSTEM
>>>
>>>
>> STUPID_TYPE_SYSTEM? No need to be insulting. It's unpleasant.
>>
>
> Well it right now it is stupid, this is just a work around anyways until
> people fix the typ
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 (
, 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
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
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
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
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
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,
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
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
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
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
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
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
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.
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
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
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
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
1 - 100 of 235 matches
Mail list logo
