Hi,
On 10/23/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
introducing a tree LOOP_HEADER with single argument N (number of
iterations of the loop), that would be present in IL at the beginning of
header of each loop.
> > quite a lot at the moment). To keep the information valid, we need
> > to prevent optimizations from destroying it (e.g., if the number
> > is n_1 = n_2 - 1, and this is the last use of n_1, we do not want
> > DCE to remove it); this is easy to achieve if n_1 would be the
> > argume
> You are proposing to complete the ssa representation such that
> foreach_ssa_uses also iterates over the niter information (a bit like vrp
> modifies the ssa chains with its extra assert information). Wouldn't it
> be possible to not insert this niter information in the representation of
> the
On 11/13/06, Ferad Zyulkyarov <[EMAIL PROTECTED]> wrote:
Hi,
May you point me out some sources about writing new #pragma directives
in GCC. I looked at the internet for something to start from but
unfortunately I could not find anything.
google("site:gcc.gnu.org inurl:gcc-patches pragma")
http
On 11/15/06, Sashan Govender <[EMAIL PROTECTED]> wrote:
On 11/15/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On 11/14/06, Sashan Govender <[EMAIL PROTECTED]> wrote:
> > Hi
> >
> > I was looking at the vectorizer
> > (http://gcc.gnu.org/projects/tree-ssa/vectorization.html) and noticed
> > that
On 11/15/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 11/15/06, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> There is a ddg in this patch if somebody wants the classic Allen&Kennedy
> way to look at the dependences:
>
http://gcc.gnu.org/wiki/OptimizationCourse
Hi,
If you like maths, a short book "Scheduling and Automatic Parallelization"
by Alain Darte, Yves Robert, and Frederic Vivien, not publicized as much
as the books proposed by Vladimir, provides more formal background
than what you can find in classical compiler literature.
I would also recommen
On 4/23/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote on 04/23/07 14:40:
> Any references?
Yes, at the last HiPEAC conference Grigori Fursin presented their
interactive compilation interface, which could be used for this.
http://gcc-ici.sourceforge.net/
That work is pa
Zack Weinberg wrote:
>
> and report (a) the numbers reported by the "time" command,
real0m7.819s
user0m4.442s
sys 0m0.513s
> (b) what sort of machine this is and how old, and
x86_64-unknown-linux-gnu, AMD Athlon(tm) 64 Processor 3700+
> (c) whether or not you would be willing to
Daniel Berlin wrote:
> On Thu, 2005-05-12 at 10:01 -0600, Zan Lynx wrote:
> > I'm not subscribed to the list (please CC replies to me) and this isn't
> > a real bug report, just a sort of quick check to see if its a known
> > problem.
> >
> > When I compiled openssl-0.9.7g using -O3 and -ftree-loo
Daniel Berlin wrote:
>
> Does -fno-tree-ch fix it? (i'm just curious)
>
No. It still ICEs.
Scott Robert Ladd wrote:
>
> My conclusion is the composite switches like -O2 are good only for
> general-purpose code. Anyone explicitly interested in squeezing out the
> most performance needs to do analysis and use application-specific switches.
>
Probably this situation is created by the fac
Robert Dewar wrote:
> Yes, absolutely, a compiler should generate warnings as much as possible when
> it is making these kind of assujmptions.
Then, you will like the following kind of patches:
Index: tree-data-ref.c
===
RCS file: /c
Robert van Engelen wrote:
>
> 1. After reading the paper, we concluded that the scalar evolutions are
> actually a restricted polynomial form of chains of recurrences by
> Bachmann and Zima [6,8]. Is this true? Or is there an essential
> difference with multi-variate chains of recurrences [7]?
DJ Delorie wrote:
>
> > Then, you will like the following kind of patches:
> >
> > + warning (0, "%H undefined behavior if loop runs for more than %qE
> > iterations",
> > + find_loop_location (loop), estimation);
>
> I think we would like them better if you could choose to silenc
Robert Dewar wrote:
>
> As with all warnings, you have to run this over a large test suite
> of real applications to find out whether there are too many false
> positives.
I don't really see what a false positive could be in this case. In
the patch that I have proposed, the warning is triggered
Robert Dewar wrote:
>
> and that is called a false positive if in fact the loop does
> not overrun. this sounds very dubious to me
The problem is that the compiler has no other information about the
number of iterations in the loop, otherwise it wouldn't spend cycles
on computing such estimations
Michael Veksler wrote:
> This is problematic:
> 1. I am not sure it will turn the warning off.
So you don't want a warning that cannot be turned off simply by
modifying the code. Then, I withdraw the patch that I have proposed
to implement the warning.
Hello,
I was just looking at the output of the data dep analyzer for
ltrans-1.c and I was quite surprised to see that array indexes are
analyzed twice, as in the following output:
(analyze_array
(ref = u[D.1485_16];
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = D.1485_16)
(get_scala
Daniel Berlin wrote:
> On Mon, 2005-08-01 at 17:27 +0300, Dorit Naishlos wrote:
> >
> > I don't think there was an intention to force recomputation - probably just
> > overlooked what the third argument actually stands for. These occurrences
> > could probably be changed to false.
> >
>
> Yeah,
and a flag that tests the validity of the
current Banerjee Analyzer for Data-dependences (BAD) against the
predictions of BOP. The regression flag is not enabled by default,
such that the POP will never be executed for normal uses of the
compiler.
Personnel
* Sebastian Pop
* D
Dan Kegel wrote:
> Sebastian Pop wrote:
> > [http://gcc.gnu.org/wiki/Omega%20data%20dependence%20test]
> > ...
> I can't understand a word of the proposal.
> Mabe you were trying to be funny, but it ended up being obscure.
I'm sorry. This was not my intent.
>
Dave Korn wrote:
>
> Well, I'll pitch in, because I also wasn't sure at first whether it was
> for real and what it was about, but I think I know now. Did you google
> "bill pugh omega solver" and do some background reading? It didn't take me
> too long to get the basic gist of what they're pr
Hi Laurent,
Laurent GUERBY wrote:
>
> So I'm asking for project proposals, that is to say people that think
> that their volunteer time to work on these old machine (scripts,
> compiling, ... under the limit of minimal external bandwidth use) is of
> some significant benefit to some free softwar
Laurent GUERBY wrote:
> Looks good. I think it would be slightly more secure to have people
> commit the patch with a unique name in some access-controlled CVS
> (either some subdir of the GCC one or a new local one) than relying on
> email "From" fields at the cost of minor inconvenience.
>
We a
Joe Buck wrote:
> Algorithms that are sometimes exponential can still be used if there is
> a cutoff mechanism, to abort the algorithm if it exceeds a budget. This
> assumes that we can then fall back to an algorithm that might produce
> inferior results, but will produce something usable in reaso
Joe Buck wrote:
> The problem with using time as a cutoff is that you then get results that
> can't be reproduced reliably. Better to count something that is a feature
> of the algorithm, e.g. number of executions of some inner loop, number of
> nodes visited, or the like,
On the other hand, it
Daniel Berlin wrote:
>
> Sebastian, I really think you are worrying too much.
right.
> It's pretty rare that it will take going all the way to omega to be able
> to disambiguate two dependences.
>
for dependence tests we exercise only a limited part of omega, but now
suppose that we'll use om
Hi Laurent,
Laurent GUERBY wrote:
> Here is the initial wiki page for the CompileFarm project:
>
> http://gcc.gnu.org/wiki/CompileFarm
>
> Feel free to add detailed proposals there.
>
For the moment the compile farm will host only i686 machines. I'm
proposing a project to diversify the availa
Andrew Pinski wrote:
>
> On Aug 15, 2005, at 4:03 PM, Gerald Pfeifer wrote:
>
> >Can someone else reproduce this on an i386 or some other target?
>
> This should been already fixed by:
> 2005-08-15 Sebastian Pop <[EMAIL PROTECTED]>
> PR 23386
&g
Steven Bosscher wrote:
> Hi,
>
> Something commited a few days ago had resulted in a serious performance
> hit for SPEC sixtrack on 64 bits machines... The obvious suspect is
> Sebastian Pop's scev patch. The affected targets are at least AMD64 [1]
> and PPC64 [2] but not i686 [3].
>
> Sebastia
shreyas krishnan wrote:
> Hi,
> For this simple loop, I get the following distance and direction
> vector
>
> Distance {1,-1)
> Direction (2,0)
>
> for(J = 1; J <= N-1; J++)
> for(I = 1; I <= N-1; I++)
> {
> XX = X[I+1][J];
> XY = X[I][J+1];
> }
>
>
Steven Bosscher wrote:
>
> So GCC 4.1 right now is a small compile time disaster. Are there any
> ideas for what can be done about it before releasing it?
>
I was looking at the testcase sent by Dale Johannesen both at tree
level and at rtl level:
> extern int a[];
> int foo(int w) {
> int n
Dale Johannesen wrote:
> I think this is a simple pasto; this code was evidently copied from
> the previous block:
>
I don't think that this was a simple pasto. The code looks correct.
We have the same code in tree-ssa-loop-niter.c around line 436, since
we inherited this code from the rtl-level
Daniel Berlin wrote:
>
> I agree completely.
> We need to be a lot smarter about invalidating certain types of
> expensive to compute information.
The way that we compute niter, for the moment, could be considered as
not expensive. But the fact that we think that this is inexpensive
makes us c
Dale Johannesen wrote:
> No, look closer. The version in loop-iv.c does a NEG of 'step' just
> before what's shown here. The version in tree-ssa-loop-niter.c
> doesn't. Reversing the operator does make them do the same thing.
Then, I think this is ok. But you'll have to ask a middle-end
mainta
Richard Kenner wrote:
> [Sorry for the missing line in my last message.]
>
> I'm watching it deal with
>
> # small_1 = PHI <32(0), 1(1)>
>
> vrp_meet is called with [32, 32] and [1,1].
>
> It determines that the ranges don't intersect and then comes up with
> ~[0,0] since neither co
Hi,
I was working on improving the results of scev, when VRP has broken
the bootstrap, eliminating loops that were estimated as running a
single time. These loop bound estimates come from the undefined
behavior of accessing over the bounds of statically allocated data in
genautomata.c:
*** genau
Gabriel Dos Reis wrote:
>
> If VRP is doing what you described in the comment as "its work", then
> VRP is broken. Period. The fix is to fix VRP. It is such a C
> idomatic construct than I would not have expected any "optimizer" to
> break it. And that is very worrisome and scary.
>
Okay, VR
Thanks for all the explanations.
Richard Henderson wrote:
>
> In the case of the (fake) flexible array member, you do not know
> how large the object allocated from malloc was unless you can
> track down the actual malloc call.
>
Gabriel Dos Reis wrote:
> typedef struct {
> int dat
Steve Ellcey wrote:
>
> In the meantime I would be interested in any opinions people have on
> what level we should be writing things out at. Generic? Gimple? RTL?
Or just dumping plain C code? This is almost what the pretty printers
are doing, and the way back to the compiler is already ther
Daniel Berlin wrote:
>
> The bottom line is that personally, I'm not in love with tree-ssa or my
> code enough that I think ego should stand in the way of GCC making the
> right decision. I would hope others who have written the "shiny new
> tree optimizers" feel the same way.
>
Seconded. I
Paolo Carlini wrote:
> Hi all, hi Danny,
>
> recently I noticed a very stupid but annoying (new!) issue: comments end
> up wrongly formatted. I think there is a mismatch between the wideness
> of the "Additional Comments" free form and the wideness after which
> chars are wrapped upon the Commit.
Daniel Berlin wrote:
>
> If you attach a patch and your mail client is sane, it will be marked as
> a patch attachment to the bug
>
Okay, thanks.
Richard Guenther wrote:
> On Tue, 13 Dec 2005, Arnaud Charlet wrote:
> > Except that unlike C, Ada needs a run-time, even for simple things,
> > so you need in addition to point (using e.g. -I) to the runtime,
> > which is built under obj/gcc/ada/rts,
> >
> > so from obj/gcc directory, you can do
Hi,
I was thinking about collecting the patches to be tested dirrectly in
the gcc-patches mailing list, like the patch queue tracks new patches.
This could also be convenient for having some control by peer review
on the patches proposed for testing.
If the machines that run the bootstrap and tes
Ronny Peine wrote:
>
> -ftree-loop-linear is removed from the testingflags in gcc-4.0.2 because it
> leads to an endless loop in neural net in nbench.
Could you fill a bug report for this one?
Thanks,
Sebastian
Segher Boessenkool wrote:
> On Tue, Sep 08, 2015 at 06:39:19PM +, Aditya K wrote:
> > IIUC, in the haifa-sched.c, the default scheduling algorithm seems to be
> > top-down (before reload).
> > Is there a way to schedule the other way (bottom up), or both ways?
> >
> > As a use case for bottom
On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
> Sebastian,
>
> I have tried to build GCC with Graphite and ISL on AIX and encountered
> two problems:
>
> (1) isl/ctx.h
>
> typedef enum {
> isl_stat_error = -1,
> isl_stat_ok = 0,
> } isl_stat;
>
> GCC complains about the co
Thanks David for reporting these problems.
On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
> (2) All of the graphite*.c files include ISL headers first. This
> order is not supported by GCC development and creates conflicts for
> types and definitions provided / overridden by GCC headers,
On Fri, Nov 20, 2015 at 10:23 AM, Sven Verdoolaege wrote:
> On Fri, Nov 20, 2015 at 10:14:47AM -0600, Sebastian Pop wrote:
>> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
>> > Sebastian,
>> >
>> > I have tried to build GCC with Graphite and ISL on A
On Fri, Nov 20, 2015 at 10:43 AM, David Edelsohn wrote:
> On Fri, Nov 20, 2015 at 11:28 AM, Sebastian Pop wrote:
>> Thanks David for reporting these problems.
>>
>> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
>>> (2) All of the graphite*.c files in
Hi,
my colleague Brian has posted the instructions to set up
an AArch64 virtual machine running ubuntu on top of qemu:
http://rzycki.blogspot.com/2014/08/using-qemu-to-run-ubuntu-arm-64-bit.html
We are using this setup to bootstrap gcc on aarch64.
Sebastian
On Fri, Apr 3, 2015 at 1:10 PM, Jeff Law wrote:
> On 04/03/2015 09:41 AM, Diego Novillo wrote:
>>
>> On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote:
>> I was hesitant to offer this option, but it's certainly a good
>> starting point. The representation encodes CFG, SSA, attributes,
>> declarati
On Tue, Apr 7, 2015 at 3:33 AM, Richard Biener
wrote:
>> Having an IR that is more readable than LLVM's would be nice.
>
> I still like the idea of using C + extensions most.
+1
> As well as making the
> -fdump-tree-XXX dumps (more) valid C (+ extensions). Cut & pasting
> from dump files to gen
We also needed to adjust the gcov_version in autofdo/gcov.cc to read
0x1 for dev branches of gcc (instead of the current 0x3430372a for
some released version of GCC):
-DEFINE_uint64(gcov_version, 0x3430372a,
+DEFINE_uint64(gcov_version, 0x1,
Sebastian
On Tue, Apr 21, 2015 at 3:33 PM, Aditya K w
15 at 3:53 PM, Dehao Chen wrote:
> That's correct. For trunk, gcov_version is 0x1. We defined this as a
> flag so that you can actually change it via --gcov_version=0x1 instead
> of changing the code.
>
> Dehao
>
> On Tue, Apr 21, 2015 at 1:47 PM, Sebastian Pop wr
On Fri, Oct 12, 2018 at 2:14 PM Marc Glisse wrote:
> On Fri, 12 Oct 2018, Thomas Schwinge wrote:
>
> > Hmm, and without any OpenACC/OpenMP etc., actually the same problem is
> > also present when running the following code through the vectorizer:
> >
> >for (int tmp = 0; tmp < N_J * N_I; ++tm
On Tue, Feb 8, 2011 at 16:14, Xinliang David Li wrote:
> What are the base option set used in all the comparison? O2, O3? Some
The flags are those set by the Makefiles of the different benchmarks
(as downloaded from the web).
Setting different flags with CFLAGS=... is painful.
> of the build t
On Wed, Feb 9, 2011 at 00:20, Tony Poppleton wrote:
>> While I appreciate Phoronix as a booster site, their benchmarking
>> practice often seems very dodgy; I'd take the results with a large grain
>> of salt
>
> The main reason I posted the link in the first place was because it
> was reflecti
On Thu, May 19, 2011 at 09:21, Basile Starynkevitch
wrote:
> I am coding a pass in MELT which should ideally transform some OpenCL things
> into Gimple
I think you mean Gimple to OpenCL.
> (yes, I do know that this has been done by Andrey Belevantset et
> al in their http://www.gccsummit.org/201
On Fri, May 20, 2011 at 08:27, Basile Starynkevitch
wrote:
>> What is your definition of induction variable?
>
> The one which is used by graphite.
Ok, then you can match against the scalar evolution of a variable:
the evolution of your variable should be of the form "{a, +, 1}_x"
with "x" the nu
On Tue, May 24, 2011 at 09:09, Alexey Kravets wrote:
> There are two places in graphite-opencl where we use strcmp technique.
> The first one is the detection of privatizable variables
> (opencl_private_var_name_p) and it can be eliminated by marking all zero
> dimensional arrays as private (see p
On Thu, May 26, 2011 at 09:58, Alexey Kravets wrote:
> On 05/24/2011 10:09 PM, Sebastian Pop wrote:
>>
>> One change that I introduced sometime in February is that some reductions
>> are not translated to a zero dim array to make the dependence test work
>> on some o
Hi,
I put the scripts that we are using to test performance regressions of GCC on
git://repo.or.cz/gcc-perf-regression-tester.git and I've wrote a small
intro page
http://gcc.gnu.org/wiki/PerfRegressionTester in the hope that these scripts will
be useful to other people.
I've been thinking to ins
On Fri, Aug 12, 2011 at 12:50, Jack Howarth wrote:
> On Fri, Aug 12, 2011 at 07:35:24PM +0200, Sven Verdoolaege wrote:
>> On Fri, Aug 12, 2011 at 05:02:18PM +, Joseph S. Myers wrote:
>> > On Fri, 12 Aug 2011, Sebastian Pop wrote:
>> > > +@item Integer
Hi Richi,
On Tue, Jul 14, 2009 at 04:40, Richard
Guenther wrote:
> You misunderstood what alias-set numbers represent. Alias-set
> numbers encode type-based alias information only - which in
> your case cannot disambiguate a or Q.
>
I also have misunderstood this.
> For dependency checking you
On Tue, Jul 14, 2009 at 10:26, Richard
Guenther wrote:
> What do you mean by 'different number for each alias set'?
An alias set numbering maps alias sets to integer numbers,
and that map is one-to-one.
> If you want to have a number that is the same for all conflicting
> memory references then
On Tue, Jul 14, 2009 at 11:03, Sebastian Pop wrote:
>> Why do you need alias-set numbers?
>
> We want to represent the alias set information as an extra subscript
> on memory accesses: for example,
>
> if we have A[10] and supposing that A is in alias set 6, this woul
On Thu, Jul 16, 2009 at 10:45, Daniel Berlin wrote:
> So if i understand you right, it seems all you've done is inverted the
> existing alias/points-to sets.
> IE instead of saying A has B, C, D in it's alias set, you are saying B
> is in the alias set of A, C is in the alias set of A, D is in the
Hi,
On Thu, Jul 23, 2009 at 10:55, Jack Howarth wrote:
> Is it known yet whether the changes in cloog/ppl will require
> new soversions of those libraries or might the new cloog/ppl
> libraries be backward compatible with current gcc 4.4.x (ie have
> the same soversion number but a higher compati
On Mon, Aug 10, 2009 at 04:22, Rainer Emrich wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I build my gcc windows versions (*-pc-cygwin, *-pc-mingw32, *-w64-mingw32)
> using
> static build libraries gmp, mpfr, mpc, ppl and cloog. Configuration and
> building
> of gcc is really easy
Hi,
On Thu, Aug 13, 2009 at 04:02, Eric Fisher wrote:
> The error is reported in build2_stat, by
>
> gcc_assert (POINTER_TYPE_P (tt) && POINTER_TYPE_P (TREE_TYPE (arg0))
> && INTEGRAL_TYPE_P (TREE_TYPE (arg1))
> && useless_type_conversion_p (sizetype, TREE_TYPE (arg1)
Hi,
> Seems that use info is not updated.
>
You should put a TODO_update_ssa in the flags of prefetching pass.
With the attached patch I don't see an error.
Also, why don't you use trunk for your developments?
Sebastian
diff --git a/gcc/tree-flow.h b/gcc/tree-flow.h
index 1d2e69a..1320b5a 10064
Hi Ian,
On Tue, Nov 10, 2009 at 17:21, Ian Lance Taylor wrote:
> For the last year and a half I've been working on a gcc frontend for
> Go, a new experimental systems programming language designed by a
> small group at Google. We've just open sourced it. You can read more
> about it at http://g
Hi Toon,
On Mon, Nov 30, 2009 at 13:51, Toon Moene wrote:
> Sebastian,
>
> I saw you updated the Graphite Wiki page, and I wondered if there are any
> concrete plans on loop fusion.
>
> The reason I ask is because in Fortran (as of Fortran 90) one often sees
> assignments like:
>
> REAL, ALLOCATA
On Fri, Dec 4, 2009 at 09:41, Toon Moene wrote:
> I wonder if Graphite can do this one (or is planned to be able to):
>
> Another loop optimization that suggests itself
> is the following, trying to eliminate unnecessary
> loop constructs:
> \begin{verbatim}
> SUBROUTINE SUB(A, B, C, N, M)
>
On Fri, Dec 4, 2009 at 10:39, Tobias Grosser wrote:
> I do not believe this is already possible for arbitrary N.
>
> You would have to write a scattering function like this
>
> s0 = i+n*(j-1)
>
> What is
>
> s= i + n*j - n
> ^^^ Here is a product that is not affine linear.
Yes this is affi
On Fri, Dec 4, 2009 at 10:44, Cédric Bastoul wrote:
> I see no way to do this with affine scattering. We would need
> polynomial functions like Armin Grosslinger is doing, see
> http://www.infosun.fim.uni-passau.de/cl/publications/docs/MIP-0803.pdf
> but I think that's too slow at the moment...
I
On Fri, Dec 4, 2009 at 11:08, Cédric Bastoul wrote:
> We usually call this case (parameter times IV) "fully parametric".
> Armin Grosslinger looked at it before finding a more general solution,
I don't want the more general solution: IV * IV doesn't commonly
happen, but parameter * IV does, and o
On Wed, Jan 13, 2010 at 14:55, Rainer Emrich wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> IMHO it would be a godd idea to add the following two configure options to ppl
> configure:
> --with-gmp-include=DIR GMP include directory
> --with-gmp-lib=DIR GMP lib directory
>
> On
On Tue, Feb 9, 2010 at 12:34, Cristianno Martins
wrote:
> Hi,
>
> Thanks for the fast reply. Only one more thing: is there some way that
> I could force it to be signed??
I guess that you should wait the fixes from Tobias and Ramakrishna to
CLooG and Graphite to have the type of the IV exposed by
on was whether options like --with-cloog should cause configure
> to exit as failed when they can't be satisfied rather than proceeding?
> Does a failure to meet the required gmp/mpfr/mpc version requirements
> behave the same way or do they abort the configure process?
>
Hi,
While working on the tree-if-conv.c, I realized that the copy
of the contents of a non scalar variable are not correctly done.
The copy assignment triggers this error:
error: virtual SSA name for non-VOP decl
while verifying SSA_NAME _ifc_.2005_46 in statement
# .MEM_394 = VDEF <.MEM_475>
On Tue, Apr 13, 2010 at 13:14, Sebastian Pop wrote:
> Hi,
>
> While working on the tree-if-conv.c, I realized that the copy
> of the contents of a non scalar variable are not correctly done.
> The copy assignment triggers this error:
>
> error: virtual SSA name for non-VOP d
On Tue, Apr 13, 2010 at 14:42, Jakub Jelinek wrote:
> if (!is_gimple_reg (var))
>
> you shouldn't create SSA name and change the lhs of the stmt.
>
This worked well. Thanks Jakub!
Sebastian
On Sat, Oct 11, 2008 at 6:46 AM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> Note that we cannot really remove switches from the user, but we have to at
> least keep them as no-op for backward compatibility. Which is why I would
> like you to think twice at least as to what options you want to a
rs:
Paul H.J. Kelly, Imperial College of London, UK
Sebastian Pop, AMD, USA
Program Committee:
Albert Cohen, INRIA, France
Grigori Fursin, INRIA, France
Benedict Gaster, AMD, USA
Jan Hubicka, SuSE, Czech Republic
Paul H.J. Kelly, Imperial College of London, UK
Ondrej Lhotak, Universit
the
workshop may be invited to revise their submission for the
journal Transactions on HiPEAC, if the work is in sufficiently
mature form.
Organizers:
Paul H.J. Kelly, Imperial College of London, UK
Sebastian Pop, AMD, USA
Program Committee:
Albert Cohen, INRIA, France
Grigori Fursin, IN
On Tue, Nov 4, 2008 at 7:27 PM, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> *** DEADLINE EXTENDED UNTIL NOVEMBER 21, 2008 ***
...
> Papers due: November 7, 2008
Well, papers are now due by November 21, 2008. Sorry for the typo.
Sebastian
On Tue, Nov 4, 2008 at 11:45 AM, Roberto Bagnara <[EMAIL PROTECTED]> wrote:
> Jack Howarth wrote:
>>
>> Now that ppl 0.10 is release, what are the plans for merging
>> the cloog-ppl changes into an actual cloog release so that tarballs are
>> available for both?
>
> This is a good question for the
I do know these problems and also the place that I have to fix.
I guess a meta bug like this one "Wrong code with -O3
-fgraphite-identity on polyhedron benchmarks" is enough.
Thanks for testing,
Sebastian Pop
--
AMD - GNU Tools
On Thu, Dec 11, 2008 at 2:36 PM, Sebastian Pop wrote:
> I do know these problems and also the place that I have to fix.
>
> I guess a meta bug like this one "Wrong code with -O3
> -fgraphite-identity on polyhedron benchmarks" is enough.
>
I just opened a bug that
xgcc that doesn't understand "-x c++", and of course target
> libstdc++ hasn't been built yet. Something's really wrong here - I can't
> understand why there's C++ involved or how it could work. Maybe the default
> configure options of PPL have changed to include some C++ interface that
> wasn't built by default at the time the wiki page was written?
>
> Anyway, TIA for any enlightenment anyone can provide. I could file PRs or
> patches for the first two bugs if desired,
I would highly appreciate this.
> but the third part has me totally confused, I don't know what to do
> with it.
I'm forwarding this third question to the PPL folks, hoping that they
already dealt with similar cases and probably already have a solution.
Thanks,
Sebastian Pop
--
AMD - GNU Tools
On Mon, Jan 19, 2009 at 10:45 PM, Ben Elliston wrote:
> Hi Sebastian
>
> While reading through the Graphite code on the trunk, I noticed that
> -fgraphite and -fgraphite-identity are no documented in doc/invoke.texi.
> Is this an oversight, or are these options deprecated?
These options are inten
On Mon, Jan 19, 2009 at 11:11 PM, Ben Elliston wrote:
>> > Is this an oversight, or are these options deprecated?
>>
>> These options are intentionally not documented: they should not be
>> used by programmers.
>
> Perhaps we should add a comment to common.opt to explain this?
Yes, we could apply
On Mon, Jan 19, 2009 at 11:27 PM, Ben Elliston wrote:
> On Mon, 2009-01-19 at 23:20 -0600, Sebastian Pop wrote:
>
>> > Perhaps we should add a comment to common.opt to explain this?
>>
>> Yes, we could apply this patch.
>
> Looks good to me (and I think it
On Fri, Feb 6, 2009 at 2:49 PM, Diego Novillo wrote:
> Before I can accept patches, however, I need to make sure that
> everyone has copyright assignments on file. I know that Taras, Basile
> and Le-Chun do. Sean and Grigori, do you folks have copyright papers
> already?
Grigori works for INRIA
me an email.
Thanks,
Sebastian Pop
--
AMD - GNU Tools
Hi Grigori,
On Thu, Feb 26, 2009 at 04:57, Grigori Fursin wrote:
> Hello All,
>
> I just saw an announcement that a new Google Summer of Code'2009
> (http://code.google.com/soc) will be accepting project proposals
> in a week or so. My colleagues and I would like to submit a few proposals
> so wa
1 - 100 of 187 matches
Mail list logo
