Sent from my iPhone
On Mar 6, 2009, at 7:00 PM, Silvius Rus wrote:
I'm thinking about adding bitwise dataflow analysis support to RTL.
Is this a good idea? Bad idea? Already done? Please review if
interested.
There is already some bitwise dataflow implemented in combine. And I
think
I'm thinking about adding bitwise dataflow analysis support to RTL.
Before embarking on this, I'd suggest playing with the bitwise domain
analysis that one of my students did as part of his cXprop tool:
http://www.cs.utah.edu/~coop/research/cxprop/#DOWNLOADS
This is a source-level analysis
I'm thinking about adding bitwise dataflow analysis support to RTL.
Is this a good idea? Bad idea? Already done? Please review if interested.
Thank you,
Silvius
Motivation
==
int foo(int x)
{
int i = 100;
do
{
if (x > 0)
x = x & 1; /* After this insn, all bits
I'm happy to report that the gcc-in-cxx branch can now bootstrap. That
is, the code in gcc proper can now be compiled with a C++ compiler.
My plan going forward is as follows (when we are back in stage 1):
* For each difference between trunk and gcc-in-cxx:
+ Try to implement a -Wc++-compat wa
On Fri, 6 Mar 2009, Paolo Bonzini wrote:
> Joseph S. Myers wrote:
> > On Fri, 6 Mar 2009, Geert Bosch wrote:
> >
> >>> this task may be more difficult. So lowering them early during
> >>> gimplification looks like a more reasonable plan IMHO.
> >> Right, that was my intention. Still, I'll need t
Snapshot gcc-4.4-20090306 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090306/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, 6 Mar 2009, Geert Bosch wrote:
>
> On Mar 6, 2009, at 12:22, Joseph S. Myers wrote:
> > If you add new trapping codes to GENERIC I'd recommend *not* making fold()
> > handle them. I don't think much folding is safe for the trapping codes
> > when you want to avoid either removing or intr
On Mar 6, 2009, at 12:22, Joseph S. Myers wrote:
If you add new trapping codes to GENERIC I'd recommend *not* making
fold()
handle them. I don't think much folding is safe for the trapping
codes
when you want to avoid either removing or introducing traps. Either
lower
the codes in gimpli
Laurent GUERBY wrote:
>
> On i686-linux for c,ada:
>
> 3.4.4 bootstraped 4.3.2 fine (your configuration)
> 3.4.0 bootstraped 4.3.1 fine
> 3.4.0 bootstraped trunk 143919 fine
>
> I'm not going to test more, a priori what the documentation
> currently says for Ada is correct at least for i686-lin
Ian Lance Taylor wrote:
Richard Earnshaw writes:
On Fri, 2009-03-06 at 16:09 +0100, Paolo Bonzini wrote:
If this does not work, on ARM you can also hope for something like this:
ADDR0, R1, R2
XORS R0, R2, R3
XORSMI R1, R2, R3
SWIMI #trap
On ARM you can just check
Richard Earnshaw writes:
> On Fri, 2009-03-06 at 16:09 +0100, Paolo Bonzini wrote:
>> If this does not work, on ARM you can also hope for something like this:
>>
>> ADDR0, R1, R2
>> XORS R0, R2, R3
>> XORSMI R1, R2, R3
>> SWIMI #trap
>
> On ARM you can just check for o
>> If this does not work, on ARM you can also hope for something like this:
>>
>> ADDR0, R1, R2
>> XORS R0, R2, R3
>> XORSMI R1, R2, R3
>> SWIMI #trap
>
> On ARM you can just check for overflow directly...
>
> ADDSR0, R1, R2
> SWIVS #trap
Of course,
On Mar 5, 2009, Jan Hubicka wrote:
> The patch adds mechanizm for tracking inline substitutions, so we
> actually note that on whole scope of its existence ARGUMENT is having
> same value as OTHERARGUMENT.
Beautiful!
> So if we want to have DEBUG_INSN approach, those aproaches should
> combine
On Thu, 2009-03-05 at 18:24 +0100, Laurent GUERBY wrote:
> On Tue, 2009-02-24 at 20:40 +0100, Laurent GUERBY wrote:
> > On Tue, 2009-02-24 at 19:36 +, Dave Korn wrote:
> > > Laurent GUERBY wrote:
> > > > On Tue, 2009-02-24 at 18:59 +, Dave Korn wrote:
> > > >> Laurent GUERBY wrote:
> > > >>
On Fri, 2009-03-06 at 16:09 +0100, Paolo Bonzini wrote:
> If this does not work, on ARM you can also hope for something like this:
>
> ADDR0, R1, R2
> XORS R0, R2, R3
> XORSMI R1, R2, R3
> SWIMI #trap
On ARM you can just check for overflow directly...
ADDSR
Joseph S. Myers wrote:
> On Fri, 6 Mar 2009, Geert Bosch wrote:
>
>>> this task may be more difficult. So lowering them early during
>>> gimplification looks like a more reasonable plan IMHO.
>> Right, that was my intention. Still, I'll need to add code to
>> handle the new tree codes in fold(),
On Fri, 6 Mar 2009, Paolo Bonzini wrote:
> Joseph S. Myers wrote:
> > On Fri, 6 Mar 2009, Paolo Bonzini wrote:
> >
> >> I don't think you need to introduce trapping tree codes. You can
> >> introduce them directly in the front-end as
> >
> > Multiple front ends want the same thing. This is why
Dear GCC developers,
I tried to use plugin frameworks
svn://gcc.gnu.org/svn/gcc/branches/plugin (old?) and
svn://gcc.gnu.org/svn/gcc/branches/plugins (current).
'plugin' has transform_ctrees() API. - callback on every fndecl
'plugins' has PLUGIN_CXX_CP_PRE_GENERICIZE. - only supported in C++
Joseph S. Myers wrote:
> On Fri, 6 Mar 2009, Paolo Bonzini wrote:
>
>> I don't think you need to introduce trapping tree codes. You can
>> introduce them directly in the front-end as
>
> Multiple front ends want the same thing. This is why it would be better
> to introduce the codes in GENERIC
On Fri, 6 Mar 2009, Geert Bosch wrote:
> In any case, while I'd really like to move the checked signed
> integer overflow from Gigi (GNAT-to-GNU tree translator) to
> the language independent part of GCC, I want to have the absolute
> minimum amount of changes that is necessary to achieve this goa
On Fri, 6 Mar 2009, Geert Bosch wrote:
> > this task may be more difficult. So lowering them early during
> > gimplification looks like a more reasonable plan IMHO.
>
> Right, that was my intention. Still, I'll need to add code to
> handle the new tree codes in fold(), right?
If you add new tra
On Fri, 6 Mar 2009, Paolo Bonzini wrote:
> I don't think you need to introduce trapping tree codes. You can
> introduce them directly in the front-end as
Multiple front ends want the same thing. This is why it would be better
to introduce the codes in GENERIC and have the language-independent
On Fri, 6 Mar 2009, Richard Guenther wrote:
> Well, I was thinking about detecting the pattern on the tree level instead.
>
> s_6 = x.0_2 + y.1_4;
> D.1597_7 = s_6 ^ x_1(D);
> D.1598_8 = s_6 ^ y_3(D);
> D.1599_9 = D.1597_7 & D.1598_8;
> if (D.1599_9 < 0)
> goto ;
> else
> goto
On Mar 6, 2009, at 04:11, Richard Guenther wrote:
I didn't spend too much time thinking about the trapping variants
(well, I believe it isn't that important ;)). But in general we would
have to expand the non-NV variants via the trapping expanders
if flag_trapv was true (so yeah, combining TUs
On Mar 6, 2009, at 09:15, Joseph S. Myers wrote:
It looks like only alpha and pa presently have insn patterns such as
addvsi3 that would be used by the present -ftrapv code, but I expect
several other processors also have instructions that would help in
overflow-checking code. (For example, Pow
On Fri, Mar 6, 2009 at 4:09 PM, Paolo Bonzini wrote:
> Richard Guenther wrote:
>> On Fri, Mar 6, 2009 at 3:29 PM, Paolo Bonzini wrote:
So while trapping variants can certainly be introduced it looks like
this task may be more difficult.
>>> I don't think you need to introduce trapping t
Richard Guenther writes:
> I agree. Btw, for the addition case we generate
>
> leal(%rsi,%rdi), %eax
> xorl%eax, %esi
> xorl%eax, %edi
> testl %edi, %esi
> jns .L2
> .value 0x0b0f
> .L2:
> rep
> ret
>
> wh
Richard Guenther wrote:
> On Fri, Mar 6, 2009 at 3:29 PM, Paolo Bonzini wrote:
>>> So while trapping variants can certainly be introduced it looks like
>>> this task may be more difficult.
>> I don't think you need to introduce trapping tree codes. You can
>> introduce them directly in the front-
On Fri, Mar 6, 2009 at 3:29 PM, Paolo Bonzini wrote:
>
>> So while trapping variants can certainly be introduced it looks like
>> this task may be more difficult.
>
> I don't think you need to introduce trapping tree codes. You can
> introduce them directly in the front-end as
>
> s = x +nv y
> So while trapping variants can certainly be introduced it looks like
> this task may be more difficult.
I don't think you need to introduce trapping tree codes. You can
introduce them directly in the front-end as
s = x +nv y
(((s ^ x) & (s ^ y)) < 0) ? trap () : s
d = x -nv y
(((
On Fri, 6 Mar 2009, Richard Guenther wrote:
> Ok, I didn't think of generating optimal code for the overflow checks,
> but it should be reasonably possible to if-convert the explicit
> overflow checks back to builtins that can be specially expanded
> (that would also help explicit overflow checks
Dave Korn wrote:
> Piotr Wyderski wrote:
>> Richard Guenther wrote:
>>
>>> Where is windows.h included?
>> I am not 100% sure yet -- the build process is in progress right
>> now, so I don't want to interfere. I suspect it is the one included
>> by gthr-win32.h. It contains the following lines:
>
On Fri, 6 Mar 2009, Joseph S. Myers wrote:
> On Fri, 6 Mar 2009, Richard Guenther wrote:
>
> > There is of course the problem that we have to be careful not to
> > introduce new traps via folding, a problem that doesn't exist with
> > the no-overflow variants (I can simply drop to the wrapping va
Piotr Wyderski wrote:
> Richard Guenther wrote:
>
>> Where is windows.h included?
>
> I am not 100% sure yet -- the build process is in progress right
> now, so I don't want to interfere. I suspect it is the one included
> by gthr-win32.h. It contains the following lines:
WAG: Do not pass --e
On Fri, 6 Mar 2009, Richard Guenther wrote:
> There is of course the problem that we have to be careful not to
> introduce new traps via folding, a problem that doesn't exist with
> the no-overflow variants (I can simply drop to the wrapping variants).
> With for example (a -/v 10) +/v 10 would y
On Fri, Mar 6, 2009 at 2:05 PM, Piotr Wyderski wrote:
> Richard Guenther wrote:
>
>> Where is windows.h included?
>
> I am not 100% sure yet -- the build process is in progress right
> now, so I don't want to interfere. I suspect it is the one included
> by gthr-win32.h. It contains the following
Richard Guenther wrote:
> Where is windows.h included?
I am not 100% sure yet -- the build process is in progress right
now, so I don't want to interfere. I suspect it is the one included
by gthr-win32.h. It contains the following lines:
#include
/* Now undef the windows BOOL. */
#undef BOOL
On Fri, Mar 6, 2009 at 1:48 PM, Piotr Wyderski wrote:
> This build problem has been occuring for at least a month,
> both on the most recent snapshots and on trunk.
>
> The compiler is configured as follows:
>
> ../configure --prefix=/opt/gcc-4.4.0-20090227 -v --enable-bootstrap
> --enable-version
This build problem has been occuring for at least a month,
both on the most recent snapshots and on trunk.
The compiler is configured as follows:
../configure --prefix=/opt/gcc-4.4.0-20090227 -v --enable-bootstrap
--enable-version-specific-runtime-libs --enable-static --enable-shared
--enable-sha
On Fri, Mar 6, 2009 at 12:27 PM, Bernd Roesch wrote:
> Hi,
>
> I see in compiler source there is in builtin.c lrint lrintf.so the gcc need
> no extern linker lib when i understand right.
>
> But get linker error when use them.I test compiler 3.4.0 4.3.2 and 4.4.0
>
> I also link with libgcc.but do
Hi,
I see in compiler source there is in builtin.c lrint lrintf.so the gcc need
no extern linker lib when i understand right.
But get linker error when use them.I test compiler 3.4.0 4.3.2 and 4.4.0
I also link with libgcc.but does not help
also my includes-fixed/math.h
contain a declaration
On Thu, 5 Mar 2009, Geert Bosch wrote:
> Hi Richard,
>
> Great to see that you're addressing this issue. If I understand correctly,
> for RTL all operations are always wrapping, right?
That's true (we don't have signedness information there) and I don't
plan to change that.
> I have been consid
42 matches
Mail list logo
