Re: Just what are rtx costs?
Georg-Johann Lay writes: > Richard Sandiford schrieb: >> I've been working on some patches to make insn_rtx_cost take account >> of the cost of SET_DESTs as well as SET_SRCs. But I'm slowly beginning >> to realise that I don't understand what rtx costs are supposed to represent. >> >> AIUI the rules have historically been: >> >> 1) Registers have zero cost. >> >> 2) Constants have a cost relative to that of registers. By extension, >> constants have zero cost if they are as cheap as a register. >> >> 3) With an outer code of SET, actual operations have the cost >> of the associated instruction. E.g. the cost of a PLUS >> is the cost of an addition instruction. >> >> 4) With other outer codes, actual operations have the cost >> of the combined instruction, if available, or the cost of >> a separate instruction otherwise. E.g. the cost of a NEG >> inside an AND might be zero on targets that support BIC-like >> instructions, and COSTS_N_INSNS (1) on most others. >> >> [...] >> >> But that hardly seems clean either. Perhaps we should instead make >> the SET_SRC always include the cost of the SET, even for registers, >> constants and the like. Thoughts? > > IMO a clean approach would be to query the costs of a whole insn (resp. > it's pattern) rather than the cost of an RTX. COSTS_N_INSNS already > indicates that the costs are compared to *insn* costs i.e. cost of the > whole pattern (modulo clobbers). The problem is that we sometimes want the cost of something that cannot be done using a single instruction. E.g. some CONST_INTs take several instructions to create on MIPS. In this case the costs are really measuring the cost of an emit_move_insn sequence, not a single insn. I suppose we could use emit_move_insn to create a temporary sequence and sum the cost of each individual instruction. But that's potentially expensive. Also, any change along these lines is similar to the "tie costs to .md patterns" thing that I mentioned at the end of the message. I don't really have time to work on anything so invasive, so the question is really whether we can sensibly change the costs within the current framework. > E.g. the cost of a CONST_INT is meaningless if you don't know what to do > with the constant. (set (reg:QI) (const_int 0)) might have different > cost than (set (reg:SI) (const_int 0)). That's the old modeless-CONST_INT problem though. I agree the mode makes a difference, but I think it's a separate issue. If we did pass complete instructions, each caller would have to provide a SET whose SET_DEST is an arbitrary psuedo register of the required mode. In all likelihood, we'd define a new utility function do this for us. So in the modeless-CONST_INT world, we would need to pass the mode to that utility function. But if we're prepared to pass such extra information around, we could simply do it by passing the mode directly to rtx_cost. I think the cost of a full rvalue (rather than a complete SET), should be based on the assumption that the destination is a register. So I don't the backend is missing any information in that respect. I.e. the problem doesn't seem to be lack of information, but rather lack of consistency (between registers, constants, operators, and so on). > Similar applies for an addition if you don't know if it's for > arithmetic or address offset computation inside a MEM. Yeah, that'd be bad, but I don't think we take costs at that level. Only a few places take the cost of anything "smaller" than a complete rvalue, and they either take the cost of a condition or take the cost of an operand to a "top-level" operator. The target then has the option of stopping the recursion whenever it likes. Richard
Re: Just what are rtx costs?
Hans-Peter Nilsson writes: >> But that hardly seems clean either. Perhaps we should instead make >> the SET_SRC always include the cost of the SET, even for registers, >> constants and the like. Thoughts? > > Seems more of maintaining a wart than an improvement for > consistency. So, to enumerate a few options: 1) Make the cost of a SET source X the same as the cost of (set (psuedo) X). The problem with this is that it seems inconsistent with recursive calls. The cost of a REG in a SET would become COSTS_N_INSNS (1), but the cost of a REG in a PLUS should still be 0 on most targets. (The REG has no cost over and above the PLUS itself.) Similarly, constants in a PLUS should have a cost of 0 if additions by that constant are as cheap as additions by a register. Other constants should have a higher cost. But option (1) would mean that constants in a SET that are as cheap as registers in a SET should have cost COSTS_N_INSNS (1). More expensive constants would have a higher cost. 2) Make the cost of a SET source X relative to the cost of a register source. This too is inconsistent. If an addition is as cheap as a move, the cost of PLUS with an outer code of SET should be 0. But COSTS_N_INSNS (1) still seems the best default for other outer codes, especially if the addition has to be done using a separate instruction. Also, having to subtract COSTS_N_INSNS (1) from the "natural" cost would be a bit error-prone. E.g. if you want the cost of MULT to be the number of cycles it takes, you'd need to use COSTS_N_INSNS (cycles - 1) rather than COSTS_N_INSNS (cycles). 3) Stick to the current approach in the target hook (at least AIUI) and fix up the result to suit whateer interface the middle end is using. This is really a generalisation of the idea in my original message (the one I said wasn't very clean). But perhaps it can be justified by saying that the target hook gives the cost of a _term_. That is, the costs provided by the target for terms are relative to the cost of a register. If the supplied X isn't a term, or isn't a valid term for the outer code, then the hook returns the cost of forcing X into a register. This seems to be approximately what we have now, and is probably the easiest thing for the target to provide. So when taking the cost of: (plus A B) with an outer code of SET, the caller is asking rtlanal.c:rtx_cost for the cost of: (set tmp-reg (plus A B)) And by passing (plus A B) to the target hook, rtx_cost in turn is asking for the cost of: (set tmp-reg2 (plus A B)) (set tmp-reg tmp-reg2) rtx_cost then has the responsibility of "optimising" this sequence into: (set tmp-reg (plus A B)) by deducting COSTS_N_INSNS (1) as appropriate. One side-effect of this is that the target should check for fused operations such as MULT-in-PLUS when it sees the PLUS expression. It shouldn't adjust the cost of MULT down a bit if outer_code is PLUS. But I think that's generally true anyway. When you see a MULT with an outer code of PLUS, you don't know if that PLUS was a SET_SRC or not. You do know when you see the PLUS. Another side-effect is that, if a MEM appears in a context where MEMs are not allowed, the target should give it a cost of COSTS_N_INSNS (1) higher than otherwise, to account for a separate load instruction. But perhaps it should be doing that anyway. Bleh. Maybe there just isn't a good answer here. Richard
Bootstrap with -Wmissing-prototypes doesn't work for C++
Since -Wmissing-prototypes doesn't work for C++, using C++ to bootstrap GCC makes -Wmissing-prototypes useless. You will see the -Wmissing-prototypes message in stage 1, but you won't see it in stage3 2/3. -- H.J.
RE: Bootstrap with -Wmissing-prototypes doesn't work for C++
I'm confused. Since C++ treats the lack of a prototype as a hard error, what does it mean to make -Wmissing-prototypes useless? From: gcc-ow...@gcc.gnu.org [gcc-ow...@gcc.gnu.org] On Behalf Of H.J. Lu [hjl.to...@gmail.com] Sent: Friday, August 19, 2011 9:36 AM To: GCC Development Subject: Bootstrap with -Wmissing-prototypes doesn't work for C++ Since -Wmissing-prototypes doesn't work for C++, using C++ to bootstrap GCC makes -Wmissing-prototypes useless. You will see the -Wmissing-prototypes message in stage 1, but you won't see it in stage3 2/3. -- H.J.
Re: Bootstrap with -Wmissing-prototypes doesn't work for C++
[hjl@gnu-33 gcc]$ cat x.c
int
foo (int x)
{
return x;
}
[hjl@gnu-33 gcc]$ ./xgcc -B./ -S -O -Wmissing-prototypes x.c
x.c:2:1: warning: no previous prototype for ‘foo’ [-Wmissing-prototypes]
[hjl@gnu-33 gcc]$ ./g++ -B./ -S -O -Wmissing-prototypes x.c
cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid
for Ada/AdaWhy/C/ObjC but not for C++ [enabled by default]
[hjl@gnu-33 gcc]$ ./g++ -B./ -S -O x.c
[hjl@gnu-33 gcc]$
Is this a bug?
On Fri, Aug 19, 2011 at 12:24 PM, Joe Buck wrote:
> I'm confused. Since C++ treats the lack of a prototype as a hard error, what
> does it mean to make -Wmissing-prototypes useless?
>
>
> From: gcc-ow...@gcc.gnu.org [gcc-ow...@gcc.gnu.org] On Behalf Of H.J. Lu
> [hjl.to...@gmail.com]
> Sent: Friday, August 19, 2011 9:36 AM
> To: GCC Development
> Subject: Bootstrap with -Wmissing-prototypes doesn't work for C++
>
> Since -Wmissing-prototypes doesn't work for C++, using
> C++ to bootstrap GCC makes -Wmissing-prototypes useless.
> You will see the -Wmissing-prototypes message in stage 1,
> but you won't see it in stage3 2/3.
>
> --
> H.J.
--
H.J.
RE: Bootstrap with -Wmissing-prototypes doesn't work for C++
I think the point is that the effect of -Wmissing-prototypes is always enabled
in C++, so that switch is rejected. The solution would seem to be to remove
that switch from the command line if C++ is used to build; that will produce
the intended result.
paul
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of H.J. Lu
Sent: Friday, August 19, 2011 3:34 PM
To: Joe Buck
Cc: GCC Development
Subject: Re: Bootstrap with -Wmissing-prototypes doesn't work for C++
[hjl@gnu-33 gcc]$ cat x.c
int
foo (int x)
{
return x;
}
[hjl@gnu-33 gcc]$ ./xgcc -B./ -S -O -Wmissing-prototypes x.c
x.c:2:1: warning: no previous prototype for 'foo' [-Wmissing-prototypes]
[hjl@gnu-33 gcc]$ ./g++ -B./ -S -O -Wmissing-prototypes x.c
cc1plus: warning: command line option '-Wmissing-prototypes' is valid for
Ada/AdaWhy/C/ObjC but not for C++ [enabled by default]
[hjl@gnu-33 gcc]$ ./g++ -B./ -S -O x.c
[hjl@gnu-33 gcc]$
Is this a bug?
On Fri, Aug 19, 2011 at 12:24 PM, Joe Buck wrote:
> I'm confused. Since C++ treats the lack of a prototype as a hard error, what
> does it mean to make -Wmissing-prototypes useless?
>
>
> From: gcc-ow...@gcc.gnu.org [gcc-ow...@gcc.gnu.org] On Behalf Of H.J.
> Lu [hjl.to...@gmail.com]
> Sent: Friday, August 19, 2011 9:36 AM
> To: GCC Development
> Subject: Bootstrap with -Wmissing-prototypes doesn't work for C++
>
> Since -Wmissing-prototypes doesn't work for C++, using
> C++ to bootstrap GCC makes -Wmissing-prototypes useless.
> You will see the -Wmissing-prototypes message in stage 1, but you
> won't see it in stage3 2/3.
>
> --
> H.J.
--
H.J.
Re: Bootstrap with -Wmissing-prototypes doesn't work for C++
On Fri, Aug 19, 2011 at 1:35 PM, wrote:
> I think the point is that the effect of -Wmissing-prototypes is always
> enabled in C++, so that switch is rejected. The solution would seem to be to
> remove that switch from the command line if C++ is used to build; that will
> produce the intended result.
G++ doesn't give a warning at all:
[hjl@gnu-33 gcc]$ cat x.c
int
foo (int x)
{
return x;
}
[hjl@gnu-33 gcc]$ ./g++ -B./ -Wall -S -O x.c
[hjl@gnu-33 gcc]$
> paul
>
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of H.J.
> Lu
> Sent: Friday, August 19, 2011 3:34 PM
> To: Joe Buck
> Cc: GCC Development
> Subject: Re: Bootstrap with -Wmissing-prototypes doesn't work for C++
>
> [hjl@gnu-33 gcc]$ cat x.c
> int
> foo (int x)
> {
> return x;
> }
> [hjl@gnu-33 gcc]$ ./xgcc -B./ -S -O -Wmissing-prototypes x.c
> x.c:2:1: warning: no previous prototype for 'foo' [-Wmissing-prototypes]
> [hjl@gnu-33 gcc]$ ./g++ -B./ -S -O -Wmissing-prototypes x.c
> cc1plus: warning: command line option '-Wmissing-prototypes' is valid for
> Ada/AdaWhy/C/ObjC but not for C++ [enabled by default]
> [hjl@gnu-33 gcc]$ ./g++ -B./ -S -O x.c
> [hjl@gnu-33 gcc]$
>
> Is this a bug?
>
> On Fri, Aug 19, 2011 at 12:24 PM, Joe Buck wrote:
>> I'm confused. Since C++ treats the lack of a prototype as a hard error, what
>> does it mean to make -Wmissing-prototypes useless?
>>
>>
>> From: gcc-ow...@gcc.gnu.org [gcc-ow...@gcc.gnu.org] On Behalf Of H.J.
>> Lu [hjl.to...@gmail.com]
>> Sent: Friday, August 19, 2011 9:36 AM
>> To: GCC Development
>> Subject: Bootstrap with -Wmissing-prototypes doesn't work for C++
>>
>> Since -Wmissing-prototypes doesn't work for C++, using
>> C++ to bootstrap GCC makes -Wmissing-prototypes useless.
>> You will see the -Wmissing-prototypes message in stage 1, but you
>> won't see it in stage3 2/3.
>>
>> --
>> H.J.
>
>
>
> --
> H.J.
>
--
H.J.
Re: Bootstrap with -Wmissing-prototypes doesn't work for C++
"H.J. Lu" writes:
> [hjl@gnu-33 gcc]$ cat x.c
> int
> foo (int x)
> {
> return x;
> }
> [hjl@gnu-33 gcc]$ ./xgcc -B./ -S -O -Wmissing-prototypes x.c
> x.c:2:1: warning: no previous prototype for ‘foo’ [-Wmissing-prototypes]
> [hjl@gnu-33 gcc]$ ./g++ -B./ -S -O -Wmissing-prototypes x.c
> cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid
> for Ada/AdaWhy/C/ObjC but not for C++ [enabled by default]
> [hjl@gnu-33 gcc]$ ./g++ -B./ -S -O x.c
> [hjl@gnu-33 gcc]$
>
> Is this a bug?
This is a minor missing feature, yes. We ought to implement
-Wmissing-prototypes for C++.
Ian
RE: Bootstrap with -Wmissing-prototypes doesn't work for C++
On Fri, 19 Aug 2011, Joe Buck wrote:
I'm confused. Since C++ treats the lack of a prototype as a hard error,
what does it mean to make -Wmissing-prototypes useless?
-Wmissing-prototype looks very similar to -Wmissing-declarations (which is
supported in C++ but documented as C/objC only). It requires that you
first have:
int f(int);
and only then:
int f(int){return 0;}
--
Marc Glisse
Re: Bootstrap with -Wmissing-prototypes doesn't work for C++
On Fri, Aug 19, 2011 at 2:45 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> [hjl@gnu-33 gcc]$ cat x.c
>> int
>> foo (int x)
>> {
>> return x;
>> }
>> [hjl@gnu-33 gcc]$ ./xgcc -B./ -S -O -Wmissing-prototypes x.c
>> x.c:2:1: warning: no previous prototype for ‘foo’ [-Wmissing-prototypes]
>> [hjl@gnu-33 gcc]$ ./g++ -B./ -S -O -Wmissing-prototypes x.c
>> cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid
>> for Ada/AdaWhy/C/ObjC but not for C++ [enabled by default]
>> [hjl@gnu-33 gcc]$ ./g++ -B./ -S -O x.c
>> [hjl@gnu-33 gcc]$
>>
>> Is this a bug?
>
> This is a minor missing feature, yes. We ought to implement
> -Wmissing-prototypes for C++.
>
I opened:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134
--
H.J.
gcc-4.6-20110819 is now available
Snapshot gcc-4.6-20110819 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110819/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 177916 You'll find: gcc-4.6-20110819.tar.bz2 Complete GCC MD5=b14d22730f9085eab7fd927039e68d28 SHA1=027de4794afc4e22f53b7fc82fcd886e8c7fe4c9 Diffs from 4.6-20110812 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Bootstrap with -Wmissing-prototypes doesn't work for C++
On Fri, Aug 19, 2011 at 4:45 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> [hjl@gnu-33 gcc]$ cat x.c
>> int
>> foo (int x)
>> {
>> return x;
>> }
>> [hjl@gnu-33 gcc]$ ./xgcc -B./ -S -O -Wmissing-prototypes x.c
>> x.c:2:1: warning: no previous prototype for ‘foo’ [-Wmissing-prototypes]
>> [hjl@gnu-33 gcc]$ ./g++ -B./ -S -O -Wmissing-prototypes x.c
>> cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid
>> for Ada/AdaWhy/C/ObjC but not for C++ [enabled by default]
>> [hjl@gnu-33 gcc]$ ./g++ -B./ -S -O x.c
>> [hjl@gnu-33 gcc]$
>>
>> Is this a bug?
>
> This is a minor missing feature, yes. We ought to implement
> -Wmissing-prototypes for C++.
>
what would it do? There is no notion of `prototype' in C++ (as C
programmers understand it).
So, what would it mean to warn about something we can't take the
negation of? ;-)
-- Gaby
Re: Bootstrap with -Wmissing-prototypes doesn't work for C++
Gabriel Dos Reis writes: > what would it do? There is no notion of `prototype' in C++ (as C > programmers understand it). > So, what would it mean to warn about something we can't take the > negation of? ;-) -Wmissing-prototypes means that if the compiler sees a globally visible function definition, it warns if no previous definition of the function was seen. This is a way of ensuring that the file which defines a function #includes the header file which declares the function, thus ensuring that the definition matches the declaration. Although the name is wrong for C++, the option is meaningful for C++ just as it is for C. (I actually sent a patch implementing this option to RMS back when I was first starting to work with gcc, although I think he rewrote it.) Ian
Re: Bootstrap with -Wmissing-prototypes doesn't work for C++
On Fri, Aug 19, 2011 at 11:17 PM, Ian Lance Taylor wrote: > Gabriel Dos Reis writes: > >> what would it do? There is no notion of `prototype' in C++ (as C >> programmers understand it). >> So, what would it mean to warn about something we can't take the >> negation of? ;-) > > -Wmissing-prototypes means that if the compiler sees a globally visible > function definition, it warns if no previous definition of the function > was seen. This is a way of ensuring that the file which defines a > function #includes the header file which declares the function, thus > ensuring that the definition matches the declaration. Although the name > is wrong for C++, the option is meaningful for C++ just as it is for C. So that is -Wmissing-declaration if I understand correctly? By "globally visible function definition" do you also include member functions? That would be unusual. I am also concerned that it would mean that a non-member inline function would have to be declared first, as that is not the case for colloquial C++. I understand what the `prototype' notion is immensely useful in C. But the problem it was designed to help mitigate has been cured long in C++, and I worry that trying to placate that to modern C++ would lead to non-colloquial C++. > > (I actually sent a patch implementing this option to RMS back when I was > first starting to work with gcc, although I think he rewrote it.) > > Ian >
