Re: invalid insn generated
I have already have both and it still does that.
It seems that after we get here, nothing would stop gcc from emiting
such an invalid insn (tem = emit_insn (gen_move_insn (out, in));). So
I think that maybe the problem is that I got there with these in and
out arguments.
2010/6/23, Ian Lance Taylor :
> roy rosen writes:
>
> > In my port I get to gen_reload to the lines
> >
> > /* If IN is a simple operand, use gen_move_insn. */
> > else if (OBJECT_P (in) || GET_CODE (in) == SUBREG)
> > {
> > static int xxx;
> > xxx = OBJECT_P (in);
> > tem = emit_insn (gen_move_insn (out, in));
> > /* IN may contain a LABEL_REF, if so add a REG_LABEL_OPERAND note. */
> > mark_jump_label (in, tem, 0);
> > }
> >
> > the emit_insn which should emit a move insn gets as out a register
> > from class D and as in the Stack pointer.
> > In my port there is no insn which can write directly from sp to d. so
> > the emitted insn is invalid and the compilation terminates.
> >
> > What might be the problem?
> > Is it possible to arrive to this point with such arguments and later
> > to fix it or does the problem begin earlier somewhere.
>
> This tends to mean that you haven't set REGISTER_MOVE_COST correctly.
> You need to make sure that moves between register class D and the
> stack pointer have a cost greater than 2. If you are unlucky you may
> have to introduce a secondary reload.
>
> Ian
>
Re: gengtype needs for C++?
On 06/29/2010 06:48 PM, Basile Starynkevitch wrote:
On Tue, 2010-06-29 at 11:40 +0200, Paolo Bonzini wrote:
On 06/29/2010 04:16 AM, Tom Tromey wrote:
Ian> In Tom's interesting idea, we would write the mark function by hand for
Ian> each C++ type that we use GTY with.
I think we should be clear that the need to write a mark function for a
new type is a drawback of this approach. Perhaps gengtype could still
write the functions for ordinary types in GCC, just not (templatized)
containers.
Yes, gengtype would emit template specializations instead of its own
mangled function names, and it would just call the same function (e.g.
gt_mark) instead of using mangled names. The C++ front-end would pick
up the correct function.
It seems very complicated to me (and apparently different from current
gengtype behavior), and I don't understand why should gengtype emit
template specializations instead of simple code. Of course, I am only
thinking of gengtype generated routines.
Or probably I did not understood what you mean. Could you give a simple
example please?
Now:
/* A zillion macros like this one: */
extern void gt_ggc_mx_throw_stmt_node (void *);
#define gt_ggc_m_20ssa_operand_memory_d(X) do { \
if (X != NULL) gt_ggc_mx_ssa_operand_memory_d (X);\
} while (0)
/* Many functions like this: */
void
gt_ggc_mx_eh_catch_d (void *x_p)
{
struct eh_catch_d * const x = (struct eh_catch_d *)x_p;
if (ggc_test_and_set_mark (x))
{
gt_ggc_m_10eh_catch_d ((*x).next_catch);
gt_ggc_m_10eh_catch_d ((*x).prev_catch);
gt_ggc_m_9tree_node ((*x).type_list);
gt_ggc_m_9tree_node ((*x).filter_list);
gt_ggc_m_9tree_node ((*x).label);
}
}
/* For each VEC, a function like this: */
void
gt_ggc_mx_VEC_eh_region_gc (void *x_p)
{
struct VEC_eh_region_gc * const x = (struct VEC_eh_region_gc *)x_p;
if (ggc_test_and_set_mark (x))
{
{
size_t i0;
size_t l0 = (size_t)(((*x).base).num);
for (i0 = 0; i0 != l0; i0++) {
gt_ggc_m_11eh_region_d ((*x).base.vec[i0]);
}
}
}
}
After:
/* Two templates like these: */
template static inline void
ggc_mark_all (T *const x)
{
if (x != NULL) ggc_mark_all_1 (x);
}
template static inline void
ggc_mark_all_1 (T *const x)
{
gcc_unreachable();
}
/* Many specializations like this (generated by gengtype). */
template <> void
ggc_mark_all_1 (struct eh_catch_d * const x)
{
if (ggc_test_and_set_mark (x))
{
ggc_mark_all ((*x).next_catch);
ggc_mark_all ((*x).prev_catch);
ggc_mark_all ((*x).type_list);
ggc_mark_all ((*x).filter_list);
ggc_mark_all ((*x).label);
}
}
/* A single specialization for all std::vectors, whose treatment
is simpler than VECs in gengtype: */
template > void
ggc_mark_all_1 (std::vector * const x)
{
typedef typename std::vector vec_type;
typedef typename vec_type::iterator iterator;
for (iterator p = x.begin(), q = x.end(); p != q; ++p)
gcc_mark_all (*p);
}
Of course it may be too bad for compilation times, it may require other
changes (e.g. to the way roots are enumerated, or because templates
require stuff to be in header files that used to be in gtype-desc.c), it
may not work at all. No idea. :)
Paolo
Re: gengtype needs for C++?
On Wed, Jun 30, 2010 at 11:51:46AM +0200, Paolo Bonzini wrote:
>
> Now:
>
> /* A zillion macros like this one: */
[...]
>
>
> After:
>
> /* Two templates like these: */
> template static inline void
> ggc_mark_all (T *const x)
> {
> if (x != NULL) ggc_mark_all_1 (x);
> }
>
> template static inline void
> ggc_mark_all_1 (T *const x)
> {
> gcc_unreachable();
> }
>
> /* Many specializations like this (generated by gengtype). */
> template <> void
> ggc_mark_all_1 (struct eh_catch_d * const x)
> {
> if (ggc_test_and_set_mark (x))
> {
> ggc_mark_all ((*x).next_catch);
> ggc_mark_all ((*x).prev_catch);
> ggc_mark_all ((*x).type_list);
> ggc_mark_all ((*x).filter_list);
> ggc_mark_all ((*x).label);
> }
> }
>
> /* A single specialization for all std::vectors, whose treatment
>is simpler than VECs in gengtype: */
> template > void
> ggc_mark_all_1 (std::vector * const x)
> {
> typedef typename std::vector vec_type;
> typedef typename vec_type::iterator iterator;
>
> for (iterator p = x.begin(), q = x.end(); p != q; ++p)
> gcc_mark_all (*p);
> }
>
>
> Of course it may be too bad for compilation times, it may require
> other changes (e.g. to the way roots are enumerated, or because
> templates require stuff to be in header files that used to be in
> gtype-desc.c), it may not work at all. No idea. :)
Thanks for the nice explanations.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
call_value problem: var = func() !?
Hello,
I'm working on a new gcc target and trying to implement call_value.
When compiling (-O0 -S) the following c code :
int f1(int a, int b)
{
int tmp = a + b;
return tmp;
}
void main()
{
int a = 10;
int b = 20;
int c;
c = f1(a,b);
}
I get the following error:
f1.c: In function 'f1':
f1.c:5:1: error: unrecognizable insn:
(insn 12 11 13 3 f1.c:4
(set (mem/c/i:SI (reg/f:SI 23 [ D.1964 ]) [0 +0 S4 A32])
(mem/c/i:SI (plus:SI (reg/f:SI 19 virtual-stack-vars)
(const_int -4 [0xfffc]))
[0 tmp+0 S4 A32])) -1 (nil))
I defined expanders and insns only for moving between registers, set
registers with immediate and moving from mem to register and vice versa.
Moving from mem to mem is not allowed. So shouldn't gcc try to force
one of the two mem addresses in a register? I don't even know if that's
what causing the error.
This is the call_value implementation in .md:
(define_expand "call_value"
[(parallel [(set (match_operand 0 "register_operand" "")
(call (match_operand 1 "general_operand" "")
(match_operand 2 "")))
(clobber (reg:SI RETURN_ADDR_REGNUM))])]
""
{
rtx dest = XEXP(operands[1], 0);
if(!call_operand(dest, Pmode))
dest = force_reg(Pmode, dest);
emit_call_insn(gen_call_value_internal(operands[0], dest, operands[2]));
DONE;
})
(define_insn "call_value_internal"
[(parallel [(set (match_operand 0 "register_operand" "")
(call (match_operand 1 "general_operand" "")
(match_operand 2 "")))
(clobber (reg:SI RETURN_ADDR_REGNUM))])]
""
"bal\t%1")
And this is my function_value:
rtx
function_value(const_tree valtype, const_tree func, enum machine_mode mode)
{
/* first step is an integer-C compiler */
/*G_RET return value reg num = %r1 .*/
return gen_rtx_REG(SImode, G_RET);
}
I'd be grateful for any help.
Kind regards.
--
if [ $(uname) = "Linux" ];then echo
"[q]sb[lv0=blv256%Plv256/svlcx]sc911084920508\
6363247337574050075032905184391195412274100697358608023133864165787933915045683\
432087129472907338347329339706073226139582008068077725378669120069632svlcxq"|dc;fi;
Re: invalid insn generated
roy rosen writes:
> I have already have both and it still does that.
> It seems that after we get here, nothing would stop gcc from emiting
> such an invalid insn (tem = emit_insn (gen_move_insn (out, in));). So
> I think that maybe the problem is that I got there with these in and
> out arguments.
That's correct. You need to figure out how to make that not happen.
(That was the actually the goal of my suggestion, although I didn't say
it, and I guess it was not helpful in any case.)
Ian
> 2010/6/23, Ian Lance Taylor :
>> roy rosen writes:
>>
>> > In my port I get to gen_reload to the lines
>> >
>> > /* If IN is a simple operand, use gen_move_insn. */
>> > else if (OBJECT_P (in) || GET_CODE (in) == SUBREG)
>> > {
>> > static int xxx;
>> > xxx = OBJECT_P (in);
>> > tem = emit_insn (gen_move_insn (out, in));
>> > /* IN may contain a LABEL_REF, if so add a REG_LABEL_OPERAND note.
>> > */
>> > mark_jump_label (in, tem, 0);
>> > }
>> >
>> > the emit_insn which should emit a move insn gets as out a register
>> > from class D and as in the Stack pointer.
>> > In my port there is no insn which can write directly from sp to d. so
>> > the emitted insn is invalid and the compilation terminates.
>> >
>> > What might be the problem?
>> > Is it possible to arrive to this point with such arguments and later
>> > to fix it or does the problem begin earlier somewhere.
>>
>> This tends to mean that you haven't set REGISTER_MOVE_COST correctly.
>> You need to make sure that moves between register class D and the
>> stack pointer have a cost greater than 2. If you are unlucky you may
>> have to introduce a secondary reload.
>>
>> Ian
>>
Re: call_value problem: var = func() !?
On 06/30/2010 05:06 AM, M. -Eqbal Maraqa wrote:
> f1.c:5:1: error: unrecognizable insn:
> (insn 12 11 13 3 f1.c:4
>(set (mem/c/i:SI (reg/f:SI 23 [ D.1964 ]) [0 +0 S4 A32])
> (mem/c/i:SI (plus:SI (reg/f:SI 19 virtual-stack-vars)
> (const_int -4 [0xfffc]))
> [0 tmp+0 S4 A32])) -1 (nil))
I strongly suspect that your movsi expander is incorrect.
> This is the call_value implementation in .md:
>
> (define_expand "call_value"
> [(parallel [(set (match_operand 0 "register_operand" "")
> (call (match_operand 1 "general_operand" "")
> (match_operand 2 "")))
> (clobber (reg:SI RETURN_ADDR_REGNUM))])]
> ""
> {
>rtx dest = XEXP(operands[1], 0);
>
>if(!call_operand(dest, Pmode))
> dest = force_reg(Pmode, dest);
>
>emit_call_insn(gen_call_value_internal(operands[0], dest, operands[2]));
>DONE;
> })
>
> (define_insn "call_value_internal"
> [(parallel [(set (match_operand 0 "register_operand" "")
> (call (match_operand 1 "general_operand" "")
> (match_operand 2 "")))
> (clobber (reg:SI RETURN_ADDR_REGNUM))])]
>
> ""
> "bal\t%1")
You've missed that the operand to call is always a mem. Most
ports look through this mem immediately, e.g.
(call (mem (match_operand:P 1 "register_operand" "r"))
(match_operand 2 ""))
Have another look at how the other ports expand and implement call.
r~
Re: Patch pinging
NightStrike writes: > [...] >> So who actually said no? > > The Frederic guy didn't like my fake-looking fake name, and wanted a > real-looking-but-just-as-fake name, or he wouldn't create a account > for me. In consultation with other overseers, I rejected your request. I did not ask for a "real-looking-but-just-as-fake name", but a "real name". You falsely presume zero vetting. > He then ignored my followup emails asking for clarification. You said no. There was nothing further to discuss. - FChE
Re: Patch pinging
On Wed, Jun 30, 2010 at 1:13 PM, Frank Ch. Eigler wrote: > > NightStrike writes: > >> [...] >>> So who actually said no? >> >> The Frederic guy didn't like my fake-looking fake name, and wanted a >> real-looking-but-just-as-fake name, or he wouldn't create a account >> for me. > > In consultation with other overseers, I rejected your request. I did > not ask for a "real-looking-but-just-as-fake name", but a "real name". > You falsely presume zero vetting. You missed my point, then. What's in a name? How would you know if what I told you was true or not? >> He then ignored my followup emails asking for clarification. > > You said no. There was nothing further to discuss. Not exactly. I offered you an alternative, and I asked you a question. You ignored both. You could very well have given me feedback, explained what was going on, let me know that I was rejected, or any of a dozen other things.
Re: Patch pinging
On 06/30/2010 07:32 PM, NightStrike wrote: >> In consultation with other overseers, I rejected your request. I did >> not ask for a "real-looking-but-just-as-fake name", but a "real name". >> You falsely presume zero vetting. >> > You missed my point, then. What's in a name? How would you know if > what I told you was true or not? > How many liars do you think are actively contributing to GCC? Just a guess... Paolo.
Re: Patch pinging
On Wed, Jun 30, 2010 at 1:41 PM, Paolo Carlini wrote: > On 06/30/2010 07:32 PM, NightStrike wrote: >>> In consultation with other overseers, I rejected your request. I did >>> not ask for a "real-looking-but-just-as-fake name", but a "real name". >>> You falsely presume zero vetting. >>> >> You missed my point, then. What's in a name? How would you know if >> what I told you was true or not? >> > How many liars do you think are actively contributing to GCC? Just a > guess... > > Paolo. > No idea. I've been emailed offlist by 3 people that used fake names. Or at least claimed to.
Re: Patch pinging
On 06/30/2010 07:44 PM, NightStrike wrote: > No idea. I've been emailed offlist by 3 people that used fake names. > Or at least claimed to. > Personally, I have trouble believing that (unless we have independent evidence that they also sleep with a 44 Magnum under the napkin). In any case, personally I don't really mind which nickname people use in most of the day by day correspondence on the mailing lists, but I find entirely sensible for FSF to have on file genuine data about the contributors. Like any other profit or non-profit organization, as far as I know. Paolo.
Re: Patch pinging
I meant pillow of course ;) ;) Paolo.
Re: About gimple_body in gimple.h
On 28 June 2010 15:48, Diego Novillo wrote: > On Mon, Jun 28, 2010 at 09:38, wrote: >> Hello all, >> >> I would like to know why does gimple_body returns NULL pointer when I try to >> use it after the "cfg" pass ? Does someone have informations about the >> general use of it ? > > Because the body has been split up into the basic blocks of the CFG. > You need to use the basic block iterators to traverse the CFG (e.g., > FOR_EACH_BB_FN()). > >> Because I am trying to traverse instructions from a C program thanks to MELT >> (cf MELT branch) and I don't know if I have to traverse basic blocks with >> FOR_EACH_BB_FN iterator or if there is another solution with gimple_body. >> Basile believes that gimple_body is nearly useless. > > It is once the CFG has been built, yes. Jeremie, it may help future users if you added this information to the comment above gimple_body. I think such a small patch wouldn't need any copyright assignment. Thanks, Manuel.
Re: Patch pinging
On Wed, Jun 30, 2010 at 1:32 PM, NightStrike wrote: > On Wed, Jun 30, 2010 at 1:13 PM, Frank Ch. Eigler wrote: >> >> NightStrike writes: >> >>> [...] So who actually said no? >>> >>> The Frederic guy didn't like my fake-looking fake name, and wanted a >>> real-looking-but-just-as-fake name, or he wouldn't create a account >>> for me. >> >> In consultation with other overseers, I rejected your request. I did >> not ask for a "real-looking-but-just-as-fake name", but a "real name". >> You falsely presume zero vetting. > > You missed my point, then. What's in a name? How would you know if > what I told you was true or not? He understood your point very well. That is why Frank said, "You falsely presume zero vetting." Do you realize that your email message convey a very smug tone? - David
Re: About gimple_body in gimple.h
On Wed, 2010-06-30 at 21:15 +0200, Manuel López-Ibáñez wrote:
> On 28 June 2010 15:48, Diego Novillo wrote:
> > On Mon, Jun 28, 2010 at 09:38, wrote:
> >> Hello all,
> >>
> >> I would like to know why does gimple_body returns NULL pointer when I try
> >> to use it after the "cfg" pass ? Does someone have informations about the
> >> general use of it ?
> >
> > Because the body has been split up into the basic blocks of the CFG.
> > You needto use the basic block iterators to traverse the CFG (e.g.,
> > FOR_EACH_BB_FN()).
> >
> >> Because I am trying to traverse instructions from a C program thanks to
> >> MELT (cf MELT branch) and I don't know if I have to traverse basic blocks
> >> with FOR_EACH_BB_FN iterator or if there is another solution with
> >> gimple_body. Basile believes that gimple_body is nearly useless.
> >
> > It is once the CFG has been built, yes.
>
> Jeremie, it may help future users if you added this information to the
> comment above gimple_body. I think such a small patch wouldn't need
> any copyright assignment.
Jeremie Salvucci (who is my intern, so we work each working day
together) did all the necessary legal work to be authorized to
contribute to GCC (see some previous messages for references : he is
authorized to commit as student of Université Paris Est [Marne la
Vallée] and as intern of CEA -LIST). So Jeremie is already covered by
copyright assignment (from CEA) & disclaimer (from Univ Paris Est).
Legally as is ok (and this was checked by Paolo).
However, he still don't have any ssh account on gcc.gnu.org so he don't
not yet have in practice write (after approval) access to the Subversion
repository of GCC.
What are the concrete steps to get him such an account?
It would be much simpler (both for Jeremie & for me Basile) if he [=
Jeremie Salvucci] had his own account. For the few patches he already
contributed to the MELT branch, I committed them for him. But it would
be much simpler for him to have the ability (that is the account) to
submit on Gcc's Svn.
For practical details (e.g. preferred logins, ssh keys) ask
jeremie.salvu...@free.fr
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Patch pinging
On Wed, Jun 30, 2010 at 3:24 PM, David Edelsohn wrote: > He understood your point very well. That is why Frank said, "You > falsely presume zero vetting." Maybe I didn't get the zero vetting part, then. I thought I did, but apparently not. What does that mean in this context? Google isn't telling me. > Do you realize that your email message convey a very smug tone? No, I do not realize that. I was intending to speak matter-of-fact-ly.
Re: About gimple_body in gimple.h
On 30 June 2010 21:28, Basile Starynkevitch wrote: > > However, he still don't have any ssh account on gcc.gnu.org so he don't > not yet have in practice write (after approval) access to the Subversion > repository of GCC. > > What are the concrete steps to get him such an account? http://gcc.gnu.org/svnwrite.html (If you cannot find this information yourself, it would be extremely helpful to provide a website patch to improve its visibility) Until he has SVN write access, you (or I) can commit approved patches on Jeremie's behalf. That is not excuse to not submit patches. ;-) Cheers, Manuel.
The trunk is fronzen NOW for the mem-ref2 merge
The trunk is frozen now. I am in the process of committing a last trunk-to-branch merge and start testing of the merge (and the trunk for comparison) on x86_64-linux, ppc64-linux and ia64-linux including multilibs where appropriate. Thanks for your cooperation, Richard.
Plug-ins on Windows
Hello, I am playing around with a plug-in for gcc but recently ran into the road block that plug-ins aren't supported on Windows. Are there any plans to add support for the windows platform in the future? If not, what are the issues with supporting Windows and how much effort would it be to add support? I'm assuming that since it's not done already there has to be some difficulty somewhere... Would it be a lot faster/easier to create a custom gcc that has my plug-in compiled in directly for the windows platform? thanks, Kyle
Re: The trunk is fronzen NOW for the mem-ref2 merge
On 06/30/2010 09:59 PM, Richard Guenther wrote: > The trunk is frozen now. I am in the process of committing a > last trunk-to-branch merge and start testing of the merge > (and the trunk for comparison) on x86_64-linux, ppc64-linux > and ia64-linux including multilibs where appropriate. > Apologies, I had troubles for a couple of hours fetching email, including this one, and committed by mistake a small C++ front-end patch. In case, let me know, and I'll take care of reverting and reapply at the end of the freeze. Paolo.
Re: The trunk is fronzen NOW for the mem-ref2 merge
On Wed, Jun 30, 2010 at 10:49 PM, Paolo Carlini wrote: > On 06/30/2010 09:59 PM, Richard Guenther wrote: >> The trunk is frozen now. I am in the process of committing a >> last trunk-to-branch merge and start testing of the merge >> (and the trunk for comparison) on x86_64-linux, ppc64-linux >> and ia64-linux including multilibs where appropriate. >> > Apologies, I had troubles for a couple of hours fetching email, > including this one, and committed by mistake a small C++ front-end > patch. In case, let me know, and I'll take care of reverting and reapply > at the end of the freeze. No need. It just won't get any testing for the merge. Richard. > Paolo. >
Re: Plug-ins on Windows
On Wed, 2010-06-30 at 16:38 -0400, Kyle Girard wrote: > Hello, > > I am playing around with a plug-in for gcc but recently ran into the > road block that plug-ins aren't supported on Windows. Are there any > plans to add support for the windows platform in the future? If not, > what are the issues with supporting Windows and how much effort would it > be to add support? I'm assuming that since it's not done already there > has to be some difficulty somewhere... Disclaimer: I know nothing about Windows & I never used it (except twice a year to change a mandatory password). I absolutely know nothing about Windows programming in the WIN32 API. Back to GCC plugins. If I remember correctly, we did slightly consider using libtldl, a wrapper providing dlopen variant http://www.gnu.org/software/libtool/manual/html_node/Libltdl-interface.html but we later rejected that idea to avoid adding yet another library dependency to GCC. Apparently libltdl is supposed to work on Windows. Perhaps you could try to use it in your own variant of GCC. However, I would imagine that making the GCC trunk accept it is much more difficult (& personally I don't care that much anymore). Perhaps also they are some technical issues that makes using libltdl impractical. Maybe your concern should be to make sure that the "-rdynamic" functionality of Linux linker can be emulated on Windows. You really want most public symbols of GCC to be visible from your Windows GCC plugin. I heard it could be hard (i.e. boring) to achieve (perhaps requiring a dllexport on all public symbols of GCC). I'll be interested to know if you succeeded in making some GCC plugin work under Windows. In case you are very brave, you might even as an exercice port the MELT plugin http://gcc.gnu.org/wiki/MELT to Windows! But I am not sure it is worth the effort. Cheers.
installing with minimal sudo
Hello All,
Is there some trick so that the GCC trunk (or a branch like MELT) is
built under some user (e.g. basile) and is installed (in the
usual /usr/local prefix, which is writable by root, not by ordinary
users on most Linux systems)
My concrete need is the following
after a
make
and a
sudo make install
I sometimes have a few root-owned files in the build directory.
(eg ./gcc/b-header-vars or ./gcc/b-header-vars). I would like to avoid
that if possible (and I confess that the MELT branch Makefile.in are not
very good: I am bad at Makefile.in hacking).
Perhaps a make install INSTALL='sudo install' could be enough, but I
tend to remember I have tried that more than a year ago without success.
Or is there a mean to pass INSTALL='sudo install' at configure time?
How do you build & install GCC (trunk or some other branch) without
having any root owned files in the build directory?
Trying a lot of times a "make distclean && make install" is a very time
consuming process that I hate doing.
How do distributions makers achieve that?? IIRC they have a strict rule
that no compilation or build should run under root!
Practical advices welcome.
Cheers.
PS. On Debian, the make-kpkg command has a --rootcmd=sudo option. I am
trying to imagine the equivalent for GCC. Of course on my machine sudo
don't ask any password.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Massive performance regression from switching to gcc 4.5
On 06/24/2010 12:06 PM, Andrew Pinski wrote: On Jun 24, 2010, at 11:50 AM, Taras Glek wrote: Hi, Just wanted to give a heads up on what might be the biggest compiler-upgrade-related performance difference we've seen at Mozilla. We switched gcc4.3 for gcc4.5 and our automated benchmarking infrastructure reported 4-19% slowdown on most of our performance metrics on 32 and 64bit Linux. A lone 8% speedup was measured on the Sunspider javascript benchmark on 64bit linux. Here are some of the slowdowns reported: http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/77951ccb76b5e630# http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/624246d7d900ed41# Most of the code is compiled with -fPIC -fno-rtti -fno-exceptions -Os Stop right there. You are compiling at -Os, that is tuned for size and not speed. So the question is did the size go down? Not the speed decreased. Try at -O2 and report back. I doubt we are going to do a tradeoff for speed at -Os at all. Thanks, Andrew Pinski Good point. Looks like the actual problem is that at -Os there is less inclining happening in 4.5 vs 4.3, which results in a bigger binary and slower code. I tried 4.5 -O2 and it's actually faster than 4.3 -Os. I am happy that -O2 performance is actually pretty good, but -Os regression is going to hurt on mobile. Taras
Re: Massive performance regression from switching to gcc 4.5
On Wed, 2010-06-30 at 14:23 -0700, Taras Glek wrote:
>
> I tried 4.5 -O2 and it's actually faster than 4.3 -Os.
>
> I am happy that -O2 performance is actually pretty good, but -Os
> regression is going to hurt on mobile.
Did you try gcc-4.5 -flto -Os or gcc-4.5 -flto -O2?
It would be interesting to hear that GCC is able to LTO a program as big
as Mozilla! And figures (notably RAM, CPU time, wallclock time for
build) would be interesting.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Massive performance regression from switching to gcc 4.5
On 06/30/2010 02:26 PM, Basile Starynkevitch wrote: On Wed, 2010-06-30 at 14:23 -0700, Taras Glek wrote: I tried 4.5 -O2 and it's actually faster than 4.3 -Os. I am happy that -O2 performance is actually pretty good, but -Os regression is going to hurt on mobile. Did you try gcc-4.5 -flto -Os or gcc-4.5 -flto -O2? It would be interesting to hear that GCC is able to LTO a program as big as Mozilla! And figures (notably RAM, CPU time, wallclock time for build) would be interesting. Both whopr and flto cause gcc to segfault while building Mozilla. Taras
Re: Massive performance regression from switching to gcc 4.5
> On 06/30/2010 02:26 PM, Basile Starynkevitch wrote: >> On Wed, 2010-06-30 at 14:23 -0700, Taras Glek wrote: >> >>> I tried 4.5 -O2 and it's actually faster than 4.3 -Os. >>> >>> I am happy that -O2 performance is actually pretty good, but -Os >>> regression is going to hurt on mobile. >>> >> Did you try gcc-4.5 -flto -Os or gcc-4.5 -flto -O2? >> >> It would be interesting to hear that GCC is able to LTO a program as big >> as Mozilla! And figures (notably RAM, CPU time, wallclock time for >> build) would be interesting. >> > > Both whopr and flto cause gcc to segfault while building Mozilla. 4.5 WHOPR is completely broken. LTO is in better shape but I am not sure if we can resonably expect it to build mozilla. However I would be very happy to help getting WHOPR working for 4.6. If you can find actual simple examples where -Os is losing size and speed we can try to do something about them. Honza > > > Taras
Re: installing with minimal sudo
Quoting Basile Starynkevitch : Hello All, Is there some trick so that the GCC trunk (or a branch like MELT) is built under some user (e.g. basile) and is installed (in the usual /usr/local prefix, which is writable by root, not by ordinary users on most Linux systems) I usually install in more nonstandard locations - ones I can write to. So no sudo is required. How do you build & install GCC (trunk or some other branch) without having any root owned files in the build directory? What's the problem? you could just change the owner of the files to yourself while you are root. Or afterwards, you can delete them, as long as you can write to the directory they reside in. find builddir -user root should find them all. Then you can use command substitution, xargs, or just find itself, to chown / rm these files.
Re: installing with minimal sudo
On 30/06/2010 22:18, Basile Starynkevitch wrote: > How do you build & install GCC (trunk or some other branch) without > having any root owned files in the build directory? Run "make install" as the limited user, using a DESTDIR, then "sudo cp -R" (or similar) the installed tree into final destination. cheers, DaveK
Re: Plug-ins on Windows
Quoting Kyle Girard : Would it be a lot faster/easier to create a custom gcc that has my plug-in compiled in directly for the windows platform? Depends on how many plugins you use. The distgcc page says it's reported to work on cygwin. So you could use a cygwin distgcc to send the compile job to some other machine, or a virtual machine on the same machine, which runs a Unix or GNU system with elf object format.
Re: Plug-ins on Windows
On 30/06/2010 21:38, Kyle Girard wrote: > Hello, > > I am playing around with a plug-in for gcc but recently ran into the > road block that plug-ins aren't supported on Windows. Are there any > plans to add support for the windows platform in the future? If not, > what are the issues with supporting Windows and how much effort would it > be to add support? I'm assuming that since it's not done already there > has to be some difficulty somewhere... The main problem is that plugins rely on the property of the ELF format that you can leave undefined references in a shared library and have them filled in by symbols exported from the main exe at runtime; they use this to call the various functions exported from GCC, like register_callback, and to access global variables and so on. Although we could build plugins as Windows DLLs and have GCC load them at runtime, if those DLLs needed to refer to anything in the main GCC executable, it would have to be specifically linked to import it - and imports on Windows have to explicitly specify the name of the DLL (or executable) they are imported from. That means that the plugin would need to explicitly refer to cc1.exe or cc1plus.exe, etc; we'd need to build separate versions of the plugin for each of the different GCC language compilers. (Long term, we might be able to extend the toolchain and libltdl to co-operate to do this kind of deferred runtime linking for us, but that's not imminent.) > Would it be a lot faster/easier to create a custom gcc that > has my plug-in compiled in directly for the windows platform? Yes, much! At least for the foreseeable future. Sorry. cheers, DaveK
Re: installing with minimal sudo
On 30.06.2010 23:18, Basile Starynkevitch wrote: Practical advices welcome. Cheers. PS. On Debian, the make-kpkg command has a --rootcmd=sudo option. I am trying to imagine the equivalent for GCC. Of course on my machine sudo don't ask any password. unsure if I understand this correctly, but you could install setting DESTDIR to a temporary installation location and then copying the files later to the final location. Matthias
Re: Plug-ins on Windows
On 06/30/2010 03:46 PM, Dave Korn wrote: > Although we could build plugins as Windows DLLs and have GCC load them at > runtime, if those DLLs needed to refer to anything in the main GCC executable, > it would have to be specifically linked to import it - and imports on Windows > have to explicitly specify the name of the DLL (or executable) they are > imported from. That means that the plugin would need to explicitly refer to > cc1.exe or cc1plus.exe, etc; we'd need to build separate versions of the > plugin for each of the different GCC language compilers. > > (Long term, we might be able to extend the toolchain and libltdl to > co-operate to do this kind of deferred runtime linking for us, but that's not > imminent.) Long term we could arrange for libbackend.a to become libbackend.dll and have that library be used for plugins. The existing practice of linking back into the main executable is more or less an efficiency hack that happens to work with ELF. r~
Re: Plug-ins on Windows
> On 06/30/2010 03:46 PM, Dave Korn wrote: > > Although we could build plugins as Windows DLLs and have GCC load them at > > runtime, if those DLLs needed to refer to anything in the main GCC > > executable, > > it would have to be specifically linked to import it - and imports on > > Windows > > have to explicitly specify the name of the DLL (or executable) they are > > imported from. That means that the plugin would need to explicitly refer to > > cc1.exe or cc1plus.exe, etc; we'd need to build separate versions of the > > plugin for each of the different GCC language compilers. > > > > (Long term, we might be able to extend the toolchain and libltdl to > > co-operate to do this kind of deferred runtime linking for us, but that's > > not > > imminent.) > > Long term we could arrange for libbackend.a to become libbackend.dll and > have that library be used for plugins. The existing practice of linking > back into the main executable is more or less an efficiency hack that > happens to work with ELF. It also makes WHOPR with -fwhole-program possible on GCC. If we will want to have dynamically linkable backend library, we would need to clean up our interfaces quite a lot so frontend does not link into backend other way than by langhooks. (or make other crosslinking explicit via externally_visible) Not that would be a bad thing. I made absolutely no measurements yet if linking frotned into backend improves performance in any sensible way. Honza > > > r~
loop peeling vs TARGET_CASE_VALUES_THRESHOLD
In unroll_loop_runtime_iterations() we emit a sequence of n_peel compare/jump instructions. Why don't we honor TARGET_CASE_VALUES_THRESHOLD here, and use a tablejump when n_peel is too big?
Re: Patch pinging
Ian Lance Taylor wrote: > Thanks for the info. So there is now a provenance, which is the point: > there is a more-or-less real person associated with each contribution. > I certainly would like the FSF to move to a similar model. I agree. I do understand the rationale for the FSF's desire to hold copyright, and have a paper trail. But, at this point, I think that's making it harder to people to participate, and with no real benefit. The FSF is clinging to an outmoded policy due to a single occurrence from long ago. However, I believe that there is nothing we can do about that; I don't imagine that this is something on which RMS or the SFLC would likely move. I think that means that our only pragmatic choice is whether to be an FSF project or not. If we don't want that, then, of course, we could adopt the Linux kernel's rules on contribution instead. (We'd also give up any ability to relicense code going forward (e.g., between GPL and GFDL) since we'd likely have many copyright holders, and no practical hope of getting them all to agree on any change.) But, as long as we do want to be an FSF project, we have to play by the FSF's rules. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
