On Mar 21, 2006, at 12:34 PM, Bradley Lucier wrote:
I'm curious about whether any of the changes recently proposed to
clean up the x86-darwin port can be applied to the 64-bit PowerPC
darwin compiler;
Like what? I haven't really seen many cleanups that were x86/darwin-
specific
I'm gett
On Tue, 2006-03-21 at 22:13 -0500, Andrew MacLeod wrote:
> On Tue, 2006-03-21 at 18:00 -0500, Daniel Berlin wrote:
> > > Maybe someone can have a look at the attribute((pointer_no_escape))
> > > patch I posted a while ago. With some IPA machinery we could possibly
> > > trim down the clobber lists
On Tue, 2006-03-21 at 22:16 -0500, Andrew MacLeod wrote:
> On Tue, 2006-03-21 at 17:42 -0500, Daniel Berlin wrote:
> > On Tue, 2006-03-21 at 17:30 -0500, Andrew MacLeod wrote:
> > > On T
> > > I seem to have narrowed it down to this patch:
> > >
> > > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg
On Tue, 2006-03-21 at 17:42 -0500, Daniel Berlin wrote:
> On Tue, 2006-03-21 at 17:30 -0500, Andrew MacLeod wrote:
> > On T
> > I seem to have narrowed it down to this patch:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00908.html
> >
>
> That's quite a while ago :).
>
It was, I am su
I'm working on a port that has instructions to move bits between
64-bit floating-point and 64-bit general-purpose regs. I say "bits"
because there's no conversion between float and int: the bit pattern
is unaltered. Therefore, it's possible to use scratch FPRs for
spilling GPRs & vice-versa, and
I don't know which version is correct, but the program below
compiles fine and works with g++-3.4.2, but fails with the following
error message when compiled with g++-4.1.0...
example.cpp: In function 'typename compose::type fmap(typename
compose::type, Out (*)(In)) [with Coll = TemList, In =
> Maybe someone can have a look at the attribute((pointer_no_escape))
> patch I posted a while ago. With some IPA machinery we could possibly
> trim down the clobber lists quite a bit.
>
Well, let me confirm first that he is right. This requires a cpgram.ii
that compiles (none of the attachmen
On 3/21/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-03-21 at 17:30 -0500, Andrew MacLeod wrote:
> >
> > I seem to have narrowed it down to this patch:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00908.html
> >
>
> That's quite a while ago :).
>
> >
> >
> > Dan, this appear
On Tue, 2006-03-21 at 17:30 -0500, Andrew MacLeod wrote:
> On Tue, 2006-03-21 at 10:10 +0100, Richard Guenther wrote:
> > On 3/21/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > > On Mon, 2006-03-20 at 18:55 -0500, Andrew Pinski wrote:
> > > > On Mar 20, 2006, at 5:18 PM, Andrew MacLeod wrote:
>
On Tue, 2006-03-21 at 10:10 +0100, Richard Guenther wrote:
> On 3/21/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > On Mon, 2006-03-20 at 18:55 -0500, Andrew Pinski wrote:
> > > On Mar 20, 2006, at 5:18 PM, Andrew MacLeod wrote:
> >
> > It looks like sometime between 10/30 and 01/23 alias analy
On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
> Hi Jeff, on the subject of seeing through typecasts, I was playing around
> with VRP and noticed that the following "if" statement is not eliminated:
>
> int u (unsigned char c) {
> int i = c;
>
> if (i < 0 || i > 255)
>
On Tue, 2006-03-21 at 11:29 -0500, Diego Novillo wrote:
> On 03/21/06 03:25, Laurent GUERBY wrote:
>
> > A casual read of tree-vrp.c showed that symbolic_range_p is mostly
> > used to do nothing, did I miss something? May be it's in another file.
> >
> That's correct. We mostly punt on symbolic
64-bit powerpc-darwin results be found here:
http://www.math.purdue.edu/~lucier/gcc/test-results/4_2-2006-03-20.gz
The mail-report-with-warnings.log file is again too large to be
accepted by the gcc-testresults mail list after quite a few weeks
when it was only about 125K long.
I'm curious
At least as far as I have been able to find, there's no mention of these
anywhere in any version of the internals manual.
I think they should at least be mentioned and the similarities/differences
to ordinary call/call_value/call_pop/call_value_pop explained, because they
actually turn out t
> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes:
Mark> I would prefer it go on savannah, which is more clearly unaffiliated
Mark> with any particular commercial entity.
Ok, I submitted a request there.
Tom
On Tue, 2006-03-21 at 18:13 +0100, Duncan Sands wrote:
> Is memory use a problem here? VR_VARYING has the advantage of using
> a bit less memory. On the other hand, I guess you could introduce the
> convention that VR_RANGE with null min/mae means to use TYPE_MIN/
> TYPE_MAX, or something along
On 03/21/06 12:14, Tom Tromey wrote:
>> "Jeff" == Jeffrey A Law <[EMAIL PROTECTED]> writes:
>
> Jeff> Note that this is closely related to some of the bounds checking
> Jeff> elimination we want to support for Java one day IIRC.
>
> My understanding from the PR (21855) is that this is stuck o
> "Jeff" == Jeffrey A Law <[EMAIL PROTECTED]> writes:
Jeff> Note that this is closely related to some of the bounds checking
Jeff> elimination we want to support for Java one day IIRC.
My understanding from the PR (21855) is that this is stuck on
aliasing, not VRP -- the VRP parts supposedly
On Tuesday 21 March 2006 18:01, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 17:41 +0100, Duncan Sands wrote:
>
> > Should it be? I was surprised to see that all ranges are initialised
> > to VR_VARYING in the vrp pass, since many types have natural ranges
> > associated with them, for example [0
On Tue, 2006-03-21 at 17:41 +0100, Duncan Sands wrote:
> Should it be? I was surprised to see that all ranges are initialised
> to VR_VARYING in the vrp pass, since many types have natural ranges
> associated with them, for example [0, 255] for the above unsigned char;
> starting off with this na
On Tuesday 21 March 2006 17:15, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
>
> > Hi Jeff, on the subject of seeing through typecasts, I was playing around
> > with VRP and noticed that the following "if" statement is not eliminated:
> >
> > int u (unsigned char
On 21 March 2006 14:59, Richard Henderson wrote:
> On Mon, Mar 20, 2006 at 04:19:52PM -, Dave Korn wrote:
>> However, I might still want to make it an option for cases where debugging
>> isn't going to be important; it seems to me that the generated code should
>> still be valid.
>
> At which
On 03/21/06 03:25, Laurent GUERBY wrote:
> A casual read of tree-vrp.c showed that symbolic_range_p is mostly
> used to do nothing, did I miss something? May be it's in another file.
>
That's correct. We mostly punt on symbolic ranges because they are
fairly expensive to track. We do try to use
On Mar 21, 2006, at 11:15 AM, Jeffrey A Law wrote:
On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
Hi Jeff, on the subject of seeing through typecasts, I was playing
around
with VRP and noticed that the following "if" statement is not
eliminated:
int u (unsigned char c) {
in
On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
> Hi Jeff, on the subject of seeing through typecasts, I was playing around
> with VRP and noticed that the following "if" statement is not eliminated:
>
> int u (unsigned char c) {
> int i = c;
>
> if (i < 0 || i > 255)
>
> >>scratchslot = argument
> >>argument = stack frame size - small
> >>sp += argument
> >>argument = scratchslot
> >>sp += small
> >
> > This assumes you have a frame pointer or sp+large_offset addressing mode
> > for accessing scratchslot. In which case you could either use fp
On 21 March 2006 14:58, Richard Henderson wrote:
> On Mon, Mar 20, 2006 at 04:03:08PM -, Dave Korn wrote:
>> Do you happen to know off the top of your head when get_frame_size()
>> becomes valid?
>
> You don't get a good first-pass estimate until after all rtl
> generation has been done. Wh
On 21 March 2006 15:12, Paul Brook wrote:
> On Tuesday 21 March 2006 14:57, Richard Henderson wrote:
>> On Mon, Mar 20, 2006 at 04:03:08PM -, Dave Korn wrote:
>>> Do you happen to know off the top of your head when get_frame_size()
>>> becomes valid?
>>
>> You don't get a good first-pass est
On Tuesday 21 March 2006 14:57, Richard Henderson wrote:
> On Mon, Mar 20, 2006 at 04:03:08PM -, Dave Korn wrote:
> > Do you happen to know off the top of your head when get_frame_size()
> > becomes valid?
>
> You don't get a good first-pass estimate until after all rtl
> generation has been d
On Mon, Mar 20, 2006 at 04:19:52PM -, Dave Korn wrote:
> However, I might still want to make it an option for cases where debugging
> isn't going to be important; it seems to me that the generated code should
> still be valid.
At which point you should tail call to abort and be done with it.
S
On Mon, Mar 20, 2006 at 04:03:08PM -, Dave Korn wrote:
> Do you happen to know off the top of your head when get_frame_size()
> becomes valid?
You don't get a good first-pass estimate until after all rtl
generation has been done. Which is later than you need.
Another possibility is to allo
Richard Guenther writes:
> On 3/21/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > Take the following C code:
> > typedef long atype[];
> > typedef long atype1[];
> >
> > int NumSift (atype *a, atype1 *a1)
> > {
> >(*a)[0] = 0;
> >(*a1)[0] = 1;
> >return (*a)[0];
> > }
> >
On 3/21/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Take the following C code:
> typedef long atype[];
> typedef long atype1[];
>
> int NumSift (atype *a, atype1 *a1)
> {
>(*a)[0] = 0;
>(*a1)[0] = 1;
>return (*a)[0];
> }
> Shouldn't the aliasing set for the type atype be the same as
> > I think that it is easy for back end to make good use of
> > TYPE_MIN_VALUE/TYPE_MAX_VALUE. Namely, consider the assignment
> >
> > x := y + z * w;
> >
> > where variables y, z and w have values in the interval [0,7] and
> > x have values in [0,1000]. Pascal converts the above to the
> > foll
On 3/21/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-03-20 at 18:55 -0500, Andrew Pinski wrote:
> > On Mar 20, 2006, at 5:18 PM, Andrew MacLeod wrote:
> >
> > > I'm not sure when this happened, but I noticed on the weekend that
> > > there
> > > has been an explosion in the time spe
On Mon, 2006-03-20 at 19:47 -0700, Jeffrey A Law wrote:
> On Sat, 2006-03-18 at 10:24 +0100, Laurent GUERBY wrote:
> > On Fri, 2006-03-17 at 12:51 -0700, Jeffrey A Law wrote:
> > > I'm not suggesting the FEs deduce more types and track ranges;
> > > that would be rather absurd. What I'm saying is
36 matches
Mail list logo
