Re: Help with Dependency question
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];
> }
>
>
> Can some body explain why thats so ?
Because:
at iteration J=1, I=2 you're accessing X[I][J+1], i.e. X[2][2]
at iteration J=2, I=1 you're accessing X[I+1][J], i.e. X[2][2]
thus, you have accessed the same array location at a distance of
(1, -1) in the iteration space.
Now, if you get a lexicographically negative distance vector, you
should know that this is a wrong answer, and the cause for this is
that the current subscript coupling does not implement the delta test.
I should filter out all these cases just for ensuring that anybody
gets hurt by this one: this is already what we're doing in the
autovect branch.
Sebastian
V850 ABI?
Hi, from gcc-3.4.4/gcc/config/v850/v850.h i got some ideas about the registers (#defs REGISTER_NAMES and ADDITIONAL_REGISTER_NAMES) and about the use of them from the comments to #def REG_ALLOC_ORDER. In that file i've also read about an option "ghs", does that one switch to the Greenhills ABI? From that file i can't really conclude everything. For example i don't know if registers 20 and 21 hold the values 255 and 65535 (an optimisation on V850). The startup code in newlib assigns them, but does gcc really rely on that and uses that (this question is just an example)? Is there a description of the ABI or the ABIs available? Best regards, Torsten.
Question about merging two instructions.
Hello,
I'm working on a the sign extension elimination pass.
(see http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01087.html for details)
I would like to merge these two instructions:
(insn 1 0 2 0 (set (reg/v:Xmode r)
(sign_extend:Xmode (op:Ymode (...
(insn 2 1 3 0 (set (lhs) (rhs)))
where:
1. Xmode > Ymode
2. rhs and/or lhs may contain: (subreg:Ymode (reg/v:Xmode r) lowpart)
The extension may be redundant here.
I would like to merge these instructions and eliminate the extension,
if possible.
I tried to use simplify_replace_rtx to replace any use of (reg r) with
the right-hand-side of the extension and simplify the result.
But, it didn't work till I added this change:
Index: simplify-rtx.c
===
RCS file: /cvsroot/gcc/gcc/gcc/simplify-rtx.c,v
retrieving revision 1.243
diff -c -3 -p -r1.243 simplify-rtx.c
*** simplify-rtx.c 16 Aug 2005 02:01:27 - 1.243
--- simplify-rtx.c 21 Aug 2005 12:07:57 -
*** simplify_replace_rtx (rtx x, rtx old_rtx
*** 319,325
return simplify_gen_ternary (code, mode, op_mode, op0, op1, op2);
case RTX_EXTRA:
- /* The only case we try to handle is a SUBREG. */
if (code == SUBREG)
{
op0 = simplify_replace_rtx (SUBREG_REG (x), old_rtx, new_rtx);
--- 319,324
*** simplify_replace_rtx (rtx x, rtx old_rtx
*** 329,334
--- 328,341
GET_MODE (SUBREG_REG (x)),
SUBREG_BYTE (x));
return op0 ? op0 : x;
+ }
+ if (code == SET)
+ {
+ op0 = simplify_replace_rtx (XEXP (x, 0), old_rtx, new_rtx);
+ op1 = simplify_replace_rtx (XEXP (x, 1), old_rtx, new_rtx);
+ if ((op0 == XEXP (x, 0)) && (op1 == XEXP (x, 1)))
+ return x;
+ return gen_rtx_SET (VOIDmode, op0, op1);
}
break;
This way, when the replacement succeeds and the result instruction
is recognizable, I can eliminate the extension.
Does it seem like a good change?
Does anyone have a better solution?
Thanks,
Leehod.
Re: Question about merging two instructions.
On Sun, 21 Aug 2005, Leehod Baruch wrote:
> *** 329,334
> --- 328,341
> GET_MODE (SUBREG_REG (x)),
> SUBREG_BYTE (x));
> return op0 ? op0 : x;
> + }
> + if (code == SET)
> + {
> + op0 = simplify_replace_rtx (XEXP (x, 0), old_rtx, new_rtx);
> + op1 = simplify_replace_rtx (XEXP (x, 1), old_rtx, new_rtx);
> + if ((op0 == XEXP (x, 0)) && (op1 == XEXP (x, 1)))
> + return x;
> + return gen_rtx_SET (VOIDmode, op0, op1);
> }
> break;
>
> This way, when the replacement succeeds and the result instruction
> is recognizable, I can eliminate the extension.
>
> Does it seem like a good change?
> Does anyone have a better solution?
This approach seems reasonable. The current structure of the code
in simplify_replace_rtx is intended to handle RTL expressions rather
than patterns, so normally it would be passed just SET_SRC (pat),
instead of the whole set.
The reason why no-one has wanted/required simplify_replace_rtx to
work on SETs is that all current passes tend to be cautious about
changes to the LHS of an assignment. Performing substitution and
simplifications in the RHS/SET_SRC always produces a semantically
equivalent instruction, but blindly replacing subexpressions in
the LHS/SET_DEST can significantly change its meaning.
Hence, when combine/GCSE/CSE/reload and other RTL optimization
passes modify the target/destination of an assignment, they only
perform the transformations they expect or can guarantee are safe
(building the SET themselves), but are happy to let simplify_replace_rtx
do it's thing on the source expression.
To summarise, the change above is not unreasonable and I'd be
happy to allow this change to simplify-rtx.c, but I'd be more
cautious about where and why it was used. For example, if you're
sure nothing bad can happen in the LHS, it might be reasonable
to instead place this code in a simplify_replace_set() function.
As the SET (and perhaps support for PARALLEL) should only ever
occur at the top-level, which can then call the recursive
simplify_replace_rtx.
I hope this helps.
Roger
--
Re: Question about merging two instructions.
>>(insn 1 0 2 0 (set (reg/v:Xmode r) >>(sign_extend:Xmode (op:Ymode (... >>(insn 2 1 3 0 (set (lhs) (rhs))) > To summarise, the change above is not unreasonable and I'd be > happy to allow this change to simplify-rtx.c, but I'd be more > cautious about where and why it was used. For example, if you're > sure nothing bad can happen in the LHS, it might be reasonable > to instead place this code in a simplify_replace_set() function. I want to replace every use of (reg r) with the extension. There might be such use on the LHS, this is why the LHS might change. 1. Can you please give me an example of something bad that can happen to the LHS. Maybe I'm missing something here. 2. After calling simplify_replace_rtx I try to recognize the instruction. Is this been cautious or is it unnecessary? 3. Isn't it reasonable to expect that every instance on old_rtx will be replaced by new_rtx even if it can't be simplified? This is what I understand from the function's documentation. But actually every expressions that can't be simplified is not replaced. Thanks, Leehod.
Question about pointer arithmetics in GIMPLE
Hi,
I'm trying to implement a tree pass that warns about bad array
accesses as suggested for PR 8268 by Jeff Law. However, I have trouble
with the following:
char digit_vector[5];
const char *ggc_alloc_string(int length) {
return digit_vector + ((length - 17) * 2);
}
this translates to:
ggc_alloc_string (length)
{
const char * D.1292;
int D.1293;
long unsigned int D.1294;
char * D.1295;
char * D.1296;
D.1293 = length * 2;
D.1294 = (long unsigned int) D.1293;
D.1295 = (char *) D.1294;
D.1296 = &digit_vector + -34B; <---
D.1292 = D.1295 + D.1296;
return D.1292;
}
that is, a pointer is formed that wouldn't be legal to form from C,
and we end up with
return (char *) (long unsigned int) (length * 2) + &digit_vector[-00022];
producing a warning. Is that correct GIMPLE? If so, I fear it simply
isn't possible to do this kind of warnings after gimplification, and,
if at all possible, would have to be done in the front-end after all.
--
Falk
Re: how to compile gcc
From: drizzle drizzle <[EMAIL PROTECTED]> To: Rafael Ávila de Espíndola <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: Re: how to compile gcc Date: Sat, 20 Aug 2005 09:48:56 -0400 If you are objective is to debug gcc, then all the necessary setup is already done...Check this documentation http://gcc.gnu.org/wiki/DebuggingGCC. I have tried this method on wiki about GCC debugging. I am not sure about that and mail the procedure here to verify it, maybe someone of you could clarify for me. Thanks in advance. Here goes the my procedure on GCC debugging. 1 Generate preprocessed source code wiht option -E and redirect to a file named a.c.expand. 2 Debug cc1 by GDB with the arguments "-c a.c.expand" to cc1 Is this a reasonable procedure to debug GCC? Any suggestion and comments are highly appreciated! dz On 8/20/05, Rafael Ávila de Espíndola <[EMAIL PROTECTED]> wrote: > http://gcc.gnu.org/install/configure.html > look at --enable-checking > and > http://gcc.gnu.org/install/build.html > There are more cflags... > > The gcc/Makefile.in is also a good reference :) > > > Thanks, > > > > -Jiang > > > Rafael > Best Regards Yao Qi Bejing Institute of Technology _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: how to compile gcc
From: drizzle drizzle <[EMAIL PROTECTED]> To: Rafael Ávila de Espíndola <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: Re: how to compile gcc Date: Sat, 20 Aug 2005 09:48:56 -0400 If you are objective is to debug gcc, then all the necessary setup is already done...Check this documentation http://gcc.gnu.org/wiki/DebuggingGCC. I have tried this method on wiki about GCC debugging. I am not sure about that and mail the procedure here to verify it, maybe someone of you could clarify for me. Thanks in advance. Here goes the my procedure on GCC debugging. 1 Generate preprocessed source code wiht option -E and redirect to a file named a.c.expand. 2 Debug cc1 by GDB with the arguments "-c a.c.expand" to cc1 Is this a reasonable procedure to debug GCC? Any suggestion and comments are highly appreciated! dz On 8/20/05, Rafael Ávila de Espíndola <[EMAIL PROTECTED]> wrote: > http://gcc.gnu.org/install/configure.html > look at --enable-checking > and > http://gcc.gnu.org/install/build.html > There are more cflags... > > The gcc/Makefile.in is also a good reference :) > > > Thanks, > > > > -Jiang > > > Rafael > Best Regards Yao Qi Bejing Institute of Technology _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: Bootstrap failure on powerpc-apple-darwin8 with Ada
On Sat, Aug 20, 2005 at 10:33:21PM -0400, Daniel Berlin wrote:
> > No. How could that possibly be?
> > We can't execute code for static
> > variable initializers, so how can we gimplify?
> What do you mean by this, exactly?
If you turn a static initializer into a code sequence, then it isn't a
static initializer. By definition, it's now a dynamic initializer.
Which would be a *serious* code quality regression.
> Because analyze_expr doesn't give us any of the info we want.
And would that be because analyze_expr isn't implemented for Ada?
> The docs for analyze_expr says:
>
> This function is responsible for lowering tree nodes not
> understood by
> generic code into understandable ones or alternatively marking
> callgraph and varpool nodes referenced by the as needed.
>
> It's the "alternatively" part that makes it useless.
Not likely in this case. The variable has to exist in order to be
marked, and in this case the whole problem is that it doesn't exist.
The Ada front end would have to create the variable at minimum, and
the it's the matter of one pointer store to produce the GENERIC form
that you want.
> cxx_callgraph_analyze_expr, an implementation of this hook, simply marks
> a bunch of varpool nodes as "used" (and it doesn't even tell us which
> ones).
>
> We don't care to know whether or not it should be marked used.
> We want to know what's actually in the trees on the initializer them so
> we can do analysis.
Sure. So far I don't see a problem though.
> IE if we have something very funky like:
>
> static int c;
> static int d;
> static struct foo *a = &{&c, &d};
>
> (and if you look, andrew found a case where we are producing
> &, so this is a possibility, AFAICT)
I disbelieve you can get this in C or C++. The fragment above
is a syntax error. AFAIK, all of this is simple laziness in the
Ada front end: generating & is how things were done
at the beginning of time, and it was easier to change this in the
gimplifier than to modify the code that generated this directly.
> In the above case, we need to see the &c, &d part.
> How does analyze_expr help us here?
By transforming to
static struct foo tmp = { &c, &d };
static struct foo* a = &tmp;
r~
Re: Bootstrap failure on powerpc-apple-darwin8 with Ada
> Sure. So far I don't see a problem though.
>
>
> > IE if we have something very funky like:
> >
> > static int c;
> > static int d;
> > static struct foo *a = &{&c, &d};
> >
> > (and if you look, andrew found a case where we are producing
> > &, so this is a possibility, AFAICT)
>
> I disbelieve you can get this in C or C++. The fragment above
> is a syntax error. AFAIK, all of this is simple laziness in the
> Ada front end: generating & is how things were done
> at the beginning of time, and it was easier to change this in the
> gimplifier than to modify the code that generated this directly.
Actually we do get it for C++. See PR 23171.
Thanks,
Andrew Pinski
Re: Bootstrap failure on powerpc-apple-darwin8 with Ada
> And would that be because analyze_expr isn't implemented for Ada?
That doesn't bother me so much, actually (mainly because i don't care
about Ada). It's the fact that it's popping up in C/C++ that does.
>
> > IE if we have something very funky like:
> >
> > static int c;
> > static int d;
> > static struct foo *a = &{&c, &d};
> >
> > (and if you look, andrew found a case where we are producing
> > &, so this is a possibility, AFAICT)
>
> I disbelieve you can get this in C or C++.
That's how this whole discussion popped up originally.
Andrew discovered an equivalent C/C++ testcase that produces
&.
See PR 23171.
Since C/C++'s analyze_expr (or whatever you want to produce that code)
doesn't produce the nice code below for that testcase, we get screwed.
> The fragment above
> is a syntax error. AFAIK, all of this is simple laziness in the
> Ada front end: generating & is how things were done
> at the beginning of time, and it was easier to change this in the
> gimplifier than to modify the code that generated this directly.
>
> > In the above case, we need to see the &c, &d part.
> > How does analyze_expr help us here?
>
> By transforming to
>
> static struct foo tmp = { &c, &d };
> static struct foo* a = &tmp;
By "gimplify static initializers", i actually meant produce the code
you've listed from whatever was generating &. Nothing
more.
If analyze_expr (or something) actually did that, i'd be a very happy
man.
It doesn't, unfortunately.
Another perfectly reasonable solution would be to force us to not
generate such crap in the first place.
Re: Bootstrap failure on powerpc-apple-darwin8 with Ada
On Sun, Aug 21, 2005 at 11:32:34PM -0400, Daniel Berlin wrote: > See PR 23171. Ok. > If analyze_expr (or something) actually did that, i'd be a very happy > man. > It doesn't, unfortunately. > Another perfectly reasonable solution would be to force us to not > generate such crap in the first place. One of these two solutions will be taken. Since I've yet to look at the PR, I can't comment on whether the second is difficult or impractical. r~
GCC 4.1 Status Report (2005-08-21)
I've reviewed all 311 bugs that were targeted at 4.0.2/4.1.0 and that were marked as 4.1 regressions. My first comment is that we had a lot of bugs targeted at 4.1.0 that should never have been so targeted. Please remember that bugs that do not effect primary or secondary targets should not have a target milestone. There are several PRs that seem to have had target milestones re-added after I removed them before, though it could also be that I failed to remove the milestone, even though I added a comment to that effect. PR 17356 is an example of such a PR, though in this case it looks like it was Andrew Pinski who removed the target milestone. PR 18190 is another example. In fact, it almost looks like someone went through and methodically re-added target milestones to all the PRs for which they had been removed. If that's the case, please stop! After removing target milestones for bugs that appeared to have been spuriously marked, there are 271 bugs targeted at 4.1. (I left a few bugs that seemed to refer to languages/platforms that aren't release-critical, on the grounds that the bugs seemed to reflect generic problems, but I may remove even these as we move forward, unless C/C++ examples are added that demonstrate the genericity.) Of these, 91 are wrong-code (26), ice-on-valid, or rejects-valid. That's not too bad. There are a lot of C++ bugs -- but most are ICEs or bad/missed error messages. (Quite a few of the diagnostic messages stem from the design decision to issue warnings from the optimizers...) There are a lot of missed-optimization bugs that represent regressions. There are the usual cast of bugs relating to extensions, including things like supporting C99 features in C++. Although, overall, I feel pretty good about the fact that the *severity* of most of the open bugs is not too high, I'm not happy with the overall *quantity* of bugs. In the past, we've aimed for 100 open regressions before making the branch, and I don't think that's an unreasonable target. Therefore, as I hinted earlier, I think Stage 3 is going to have to slip. However, if ten people commit to fixing a regression a day, we should be able to reach 100 bugs in about three weeks, even allowing for some new bugs popping up as we go -- which would put us at mid-September. The most important thing is that people stop working on clean-ups and new features -- and truly concentrate on fixing bugs. I don't want to be draconian about that, but let's get the bugs fixed. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED]
