Re: Resend: [PATCH] [MIPS] Fix asm constraints for 'ins' instructions.
David Daney <[EMAIL PROTECTED]> writes:
> Ralf Baechle wrote:
>> On Wed, Jun 11, 2008 at 10:04:25AM -0700, David Daney wrote:
>>
>>> The third operand to 'ins' must be a constant int, not a register.
>>>
>>> Signed-off-by: David Daney <[EMAIL PROTECTED]>
>>> ---
>>> include/asm-mips/bitops.h |6 +++---
>>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/include/asm-mips/bitops.h b/include/asm-mips/bitops.h
>>> index 6427247..9a7274b 100644
>>> --- a/include/asm-mips/bitops.h
>>> +++ b/include/asm-mips/bitops.h
>>> @@ -82,7 +82,7 @@ static inline void set_bit(unsigned long nr, volatile
>>> unsigned long *addr)
>>> "2: b 1b \n"
>>> " .previous \n"
>>> : "=&r" (temp), "=m" (*m)
>>> - : "ir" (bit), "m" (*m), "r" (~0));
>>> + : "i" (bit), "m" (*m), "r" (~0));
>>> #endif /* CONFIG_CPU_MIPSR2 */
>>> } else if (cpu_has_llsc) {
>>> __asm__ __volatile__(
>>
>> An old trick to get gcc to do the right thing. Basically at the stage when
>> gcc is verifying the constraints it may not yet know that it can optimize
>> things into an "i" argument, so compilation may fail if "r" isn't in the
>> constraints. However we happen to know that due to the way the code is
>> written gcc will always be able to make use of the "i" constraint so no
>> code using "r" should ever be created.
>>
>> The trick is a bit ugly; I think it was used first in asm-i386/io.h ages ago
>> and I would be happy if we could get rid of it without creating new problems.
>> Maybe a gcc hacker here can tell more?
>
> It is not nice to lie to GCC.
>
> CCing GCC and Richard in hopes that a wider audience may shed some light on
> the issue.
You _might_ be able to use "i#r" instead of "ri", but I wouldn't
really recommend it. Even if it works now, I don't think there's
any guarantee it will in future.
There are tricks you could pull to detect the problem at compile time
rather than assembly time, but that's probably not a big win. And again,
I wouldn't recommend them.
I'm not saying anything you don't know here, but if the argument is
always a syntactic constant, the safest bet would be to apply David's
patch and also convert the function into a macro. I notice some other
ports use macros rather than inline functions here. I assume you've
deliberately rejected macros as being too ugly though.
Richard
Re: [lto] function to DECL associations for WPA repackaging
On Thu, Jun 12, 2008 at 3:53 AM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > Daniel Berlin wrote: >> >> On Wed, Jun 11, 2008 at 9:13 PM, Kenneth Zadeck >> <[EMAIL PROTECTED]> wrote: >> >>> >>> Richard Guenther wrote: >>> On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wrote: > > Doug, > > Yesterday, we spoke briefly about the need to efficiently determine > the DECL's required by each function. Here's a more detailed > overview. During the WPA phase of WHOPR, we will be reading in a > collection of object files, performing analysis on call-graph/summary > data, and outputting repackaged object files. This is described more > fully in the "Repackaging" section at > http://gcc.gnu.org/wiki/whopr/wpa. During a first implementation, the > output files are likely to mirror the input files with inlinable > function bodies appended. As our WPA implementation gets more > sophisticated, we will likely want to support more complex repackaging > schemes based on call-graph partitioning. > > In either case, we need a way to efficiently determine which DECL's > must accompany a given set of function bodies. DECL references are > currently stored as integral indexes within the serialized function > bodies. These need to be reproduced elsewhere. Right now, I'm > thinking the call-graph nodes are the best place for this. Kenny > might have some suggestions on this front. > > In the end, WPA should look something like this: > > 1) Read in call-graph nodes, DECL's, and summary data from the input > files. > 2) Do some analysis. Partition the functions described in the > call-graph > nodes. > 3) Scan each partition's call graph to determine which DECL's are > needed. > 4) Write each partition's function bodies, DECL's, and call-graph > nodes to an output file. > > If you could work on the DECL association logic, that would be greatly > appreciated. > > We have gimple_referenced_vars (cfun), which is a hashtable mapping the DECL_UID of every referenced variable in the function to its DECL. In the end this could be serialized as a bitmap of DECL_UIDs if you can associate DECL_UIDs with the proper DECL at repacking / de-serializing time. Richard. >>> >>> ollie is asking which global and static vars are referenced by each >>> function, not the local variables. >>> >> >> Referenced_vars already includes all of these, efficiently indexed for >> you by UID. >> Not that it is necessarily the right answer, but it includes more than >> the local variables. >> > > but we do not serialize this, and we should not. we know what global vars > each function references when we serialize it, it is not a big deal to keep > track of that as we do so and write it into a separate section that the > function body. Well, I still do not see the difference of simply serializing referenced_vars. Note that referenced_vars also includes _reachable_ globals (through static initializers). ipa-reference is useful to find statics that are never written to (it promotes them to const). Of course a proper ipa-mod-ref and proper ipa-call-clobbering would be even more useful. Richard.
Re: [lto] function to DECL associations for WPA repackaging
Richard Guenther wrote: On Thu, Jun 12, 2008 at 3:53 AM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote: On Wed, Jun 11, 2008 at 9:13 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Richard Guenther wrote: On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wrote: Doug, Yesterday, we spoke briefly about the need to efficiently determine the DECL's required by each function. Here's a more detailed overview. During the WPA phase of WHOPR, we will be reading in a collection of object files, performing analysis on call-graph/summary data, and outputting repackaged object files. This is described more fully in the "Repackaging" section at http://gcc.gnu.org/wiki/whopr/wpa. During a first implementation, the output files are likely to mirror the input files with inlinable function bodies appended. As our WPA implementation gets more sophisticated, we will likely want to support more complex repackaging schemes based on call-graph partitioning. In either case, we need a way to efficiently determine which DECL's must accompany a given set of function bodies. DECL references are currently stored as integral indexes within the serialized function bodies. These need to be reproduced elsewhere. Right now, I'm thinking the call-graph nodes are the best place for this. Kenny might have some suggestions on this front. In the end, WPA should look something like this: 1) Read in call-graph nodes, DECL's, and summary data from the input files. 2) Do some analysis. Partition the functions described in the call-graph nodes. 3) Scan each partition's call graph to determine which DECL's are needed. 4) Write each partition's function bodies, DECL's, and call-graph nodes to an output file. If you could work on the DECL association logic, that would be greatly appreciated. We have gimple_referenced_vars (cfun), which is a hashtable mapping the DECL_UID of every referenced variable in the function to its DECL. In the end this could be serialized as a bitmap of DECL_UIDs if you can associate DECL_UIDs with the proper DECL at repacking / de-serializing time. Richard. ollie is asking which global and static vars are referenced by each function, not the local variables. Referenced_vars already includes all of these, efficiently indexed for you by UID. Not that it is necessarily the right answer, but it includes more than the local variables. but we do not serialize this, and we should not. we know what global vars each function references when we serialize it, it is not a big deal to keep track of that as we do so and write it into a separate section that the function body. Well, I still do not see the difference of simply serializing referenced_vars. Note that referenced_vars also includes _reachable_ globals (through static initializers). ipa-reference is useful to find statics that are never written to (it promotes them to const). Of course a proper ipa-mod-ref and proper ipa-call-clobbering would be even more useful. i had forgotten that it did this. Richard.
Re: [lto] function to DECL associations for WPA repackaging
On 2008-06-11, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > my sense is not to associate put this directly in the cgraph but to keep it > as a side table that is indexed by something like the cgraph node id. The > reason for leaning in this direction is that "what happens in the cgraph > stays in the cgraph", and the infomation we are talking about here is is > only really useful for the whopr repackaging. This is why i have resisted > honza's wanting to associate other ipa local information in the cgraph. What we need here is a per-function symbol table. I don't think I mind if we put it together with each cgraph node or in a separate symbol table section indexed by node id. Both seem reasonable. Though I'm curious why you think storing it in the cgraph node directly is not a good idea. What each function needs to be write to this table is every symbol in gimple_referenced_vars(fn) that is marked as is_global_var(). I suppose that this table only needs to have the references to the table stored in DECL_SECTION on the output file. > We have a pass that computes this info currently, the ipa_referenced vars, You mean pass_ipa_reference()? But this is the pass that sets read/written attributes from file-globals isn't it? Diego.
Re: [lto] function to DECL associations for WPA repackaging
On Thu, Jun 12, 2008 at 1:24 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > On 2008-06-11, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > >> my sense is not to associate put this directly in the cgraph but to keep it >> as a side table that is indexed by something like the cgraph node id. The >> reason for leaning in this direction is that "what happens in the cgraph >> stays in the cgraph", and the infomation we are talking about here is is >> only really useful for the whopr repackaging. This is why i have resisted >> honza's wanting to associate other ipa local information in the cgraph. > > What we need here is a per-function symbol table. I don't think I > mind if we put it together with each cgraph node or in a separate > symbol table section indexed by node id. Both seem reasonable. > Though I'm curious why you think storing it in the cgraph node > directly is not a good idea. > > What each function needs to be write to this table is every symbol in > gimple_referenced_vars(fn) that is marked as is_global_var(). > > I suppose that this table only needs to have the references to the > table stored in DECL_SECTION on the output file. > > >> We have a pass that computes this info currently, the ipa_referenced vars, > > You mean pass_ipa_reference()? But this is the pass that sets > read/written attributes from file-globals isn't it? Yes. The referenced_vars hashtable is filled by the referenced_vars pass (see tree-dfa.c:find_referenced_vars). Richard.
Re: [lto] function to DECL associations for WPA repackaging
Diego Novillo wrote: On 2008-06-11, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: my sense is not to associate put this directly in the cgraph but to keep it as a side table that is indexed by something like the cgraph node id. The reason for leaning in this direction is that "what happens in the cgraph stays in the cgraph", and the infomation we are talking about here is is only really useful for the whopr repackaging. This is why i have resisted honza's wanting to associate other ipa local information in the cgraph. What we need here is a per-function symbol table. I don't think I mind if we put it together with each cgraph node or in a separate symbol table section indexed by node id. Both seem reasonable. Though I'm curious why you think storing it in the cgraph node directly is not a good idea. What each function needs to be write to this table is every symbol in gimple_referenced_vars(fn) that is marked as is_global_var(). I suppose that this table only needs to have the references to the table stored in DECL_SECTION on the output file. I think that if you want to cast this as we need to have a symbol table for the compiler in general then that is fine. We have talked about having a symbol table and i certainly agree that that would be useful. That was not how this was presented in the first email of this thread. It was cast as something to hold the global and static vars so that you could do a specific whopr task. To accomplish that particular task, the set of global and static vars does need to be accessible outside of the function body. However, there are specific/peculiar problems with serializing the function's symbol table outside of the function body itself. There will be no "there there" for the local variables and types, i.e. nothing escapes the function body for these to point to. Furthermore, you do not want to have these things lying around when you are trying to cherry pick because all of the local vars for all of the functions are going to be huge. Given these problems, I think that it does not make sense to serialize a symbol table (from a time and space point of view), but to simply rebuild the symbol table for a function when you read in the function body. Of course if there is info that is lost by doing this, then this will have to be revisited. But given that gcc goes to trouble of deliberately flattening all of block structure in a function, i do not see that much will be lost by just recovering the info as you deserialize the body. And so i stand behind my suggestion to do something ad hoc and not persistent for the global vars and types for whopr. We have a pass that computes this info currently, the ipa_referenced vars, You mean pass_ipa_reference()? But this is the pass that sets read/written attributes from file-globals isn't it? Diego.
Re: [lto] function to DECL associations for WPA repackaging
On 2008-06-12, Richard Guenther <[EMAIL PROTECTED]> wrote: > Yes. The referenced_vars hashtable is filled by the referenced_vars pass > (see tree-dfa.c:find_referenced_vars). Right, that's why Ken's reference to pass_ipa_reference() confused me. find_referenced_vars() is probably the oldest and simplest pass we have in the whole pipeline. Diego.
Re: [lto] function to DECL associations for WPA repackaging
On 2008-06-12, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > I think that if you want to cast this as we need to have a symbol table for > the compiler in general then that is fine. Yes, but we only need a symbol table for globals. Temporaries and locals need not be in this table. > However, there are specific/peculiar problems with serializing the > function's symbol table outside of the function body itself. There will be > no "there there" for the local variables and types This table should not have local variables in it. Only those globals referenced by the function body. Diego.
Re: [lto] function to DECL associations for WPA repackaging
Diego Novillo wrote:
On 2008-06-12, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
I think that if you want to cast this as we need to have a symbol table for
the compiler in general then that is fine.
Yes, but we only need a symbol table for globals. Temporaries and
locals need not be in this table.
However, there are specific/peculiar problems with serializing the
function's symbol table outside of the function body itself. There will be
no "there there" for the local variables and types
This table should not have local variables in it. Only those globals
referenced by the function body.
So then there are two issues here:
1) Is there any use for such a table outside of whopr? If so, then
this should be part of the cgraph. If not, then it should just be
something that is created by the serializer, and dumped out and
reconstituted by the cherry picker.
2) there is the issue that richi pointed out on irc:
[07:46]richi: i am now confused by this email thread
[07:46]zadeck: I am confused as well
[07:47]zadeck: why does referenced_vars not fit your needs?
[07:47]this is the problem with delayed communications.
[07:47]see my last email.
[07:48]oh, new mail again!
[07:48];)
[07:49]zadeck: ok, the problem is that you cannot
re-build the global vars part
[07:49]at de-serializing time
[07:50]i do not understand why you cannot
[07:50]or do you serialize globals as varpool nodes as well?
[07:50]-->|manphiz ([EMAIL PROTECTED]) has joined #gcc
[07:50]consider foo = &bar; bar = &foobar; x () { x = foo; }
[07:50]how, looking at x(), can you reach foobar?
[07:51]find_referenced_vars() puts that in the functions
referenced_vars list of x
[07:51]because optimization passes might substitute these
constant addresses walking the initializers
[07:52](of course I have no idea how you
serialize/deserialize global vars with an initializer ;))
[07:54]but that is only true if foo and bar are const
[07:54]and static
[07:54]or are marked const by ipa_reference
[07:54]sure
[07:55]but in some way we need to deal with this
[07:57]i see this issue, but the problem is that we
cannot serialize the local vars outside of the function body.
I have no idea how to make sure, in whopr, that function x sees foobar
if you are going to cherry pick the globals also.
Diego.
newlib & libgcov
Hello,
In our GCC porting, we use newlib instead of libc. Today I tried to use
profiling feedback based optimization with option -fprofile-arcs. But
the executable doesn't produce .gcda file. I examined the disassembled
binary file and found the following functions are basically just dummy
ones: __gcov_init, __gcov_flush, __gcov_merge_add. I checked libgcov.c
that contains these functions and found following code.
#if defined(inhibit_libc)
/* If libc and its header files are not available, provide dummy
functions. */
#ifdef L_gcov
void __gcov_init (struct gcov_info *p __attribute__ ((unused))) {}
void __gcov_flush (void) {}
#endif
#ifdef L_gcov_merge_add
void __gcov_merge_add (gcov_type *counters __attribute__ ((unused)),
unsigned n_counters __attribute__ ((unused))) {}
#endif
#ifdef L_gcov_merge_single
void __gcov_merge_single (gcov_type *counters __attribute__ ((unused)),
unsigned n_counters __attribute__ ((unused)))
{}
#endif
#ifdef L_gcov_merge_delta
void __gcov_merge_delta (gcov_type *counters __attribute__ ((unused)),
unsigned n_counters __attribute__ ((unused)))
{}
#endif
Both -Dinhibit_libc and -DL_gcov are used as shown in our building log
file. I guess -Dinhibit_libc is added because we used newlibc instead
of glibc. I tried to grep these functions in newlibc and didn't find
them. My question is how to enable gcov with newlibc. Do I need to
write my own versions of them? Any suggestion is greatly appreciated.
Cheers,
Bingfeng Mei
Broadcom UK
Re: Resend: [PATCH] [MIPS] Fix asm constraints for 'ins' instructions.
Richard Sandiford wrote:
> David Daney <[EMAIL PROTECTED]> writes:
>> Ralf Baechle wrote:
>>> On Wed, Jun 11, 2008 at 10:04:25AM -0700, David Daney wrote:
>>>
The third operand to 'ins' must be a constant int, not a register.
Signed-off-by: David Daney <[EMAIL PROTECTED]>
---
include/asm-mips/bitops.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-mips/bitops.h b/include/asm-mips/bitops.h
index 6427247..9a7274b 100644
--- a/include/asm-mips/bitops.h
+++ b/include/asm-mips/bitops.h
@@ -82,7 +82,7 @@ static inline void set_bit(unsigned long nr, volatile
unsigned long *addr)
"2: b 1b \n"
" .previous \n"
: "=&r" (temp), "=m" (*m)
- : "ir" (bit), "m" (*m), "r" (~0));
+ : "i" (bit), "m" (*m), "r" (~0));
#endif /* CONFIG_CPU_MIPSR2 */
} else if (cpu_has_llsc) {
__asm__ __volatile__(
>>> An old trick to get gcc to do the right thing. Basically at the stage when
>>> gcc is verifying the constraints it may not yet know that it can optimize
>>> things into an "i" argument, so compilation may fail if "r" isn't in the
>>> constraints. However we happen to know that due to the way the code is
>>> written gcc will always be able to make use of the "i" constraint so no
>>> code using "r" should ever be created.
>>>
>>> The trick is a bit ugly; I think it was used first in asm-i386/io.h ages ago
>>> and I would be happy if we could get rid of it without creating new
>>> problems.
>>> Maybe a gcc hacker here can tell more?
>> It is not nice to lie to GCC.
>>
>> CCing GCC and Richard in hopes that a wider audience may shed some light on
>> the issue.
>
> You _might_ be able to use "i#r" instead of "ri", but I wouldn't
> really recommend it. Even if it works now, I don't think there's
> any guarantee it will in future.
>
> There are tricks you could pull to detect the problem at compile time
> rather than assembly time, but that's probably not a big win. And again,
> I wouldn't recommend them.
>
> I'm not saying anything you don't know here, but if the argument is
> always a syntactic constant, the safest bet would be to apply David's
> patch and also convert the function into a macro. I notice some other
> ports use macros rather than inline functions here. I assume you've
> deliberately rejected macros as being too ugly though.
I am still a little unclear on this.
To restate the question:
static inline void f(unsigned nr, unsigned *p)
{
unsigned short bit = nr & 5;
if (__builtin_constant_p(bit)) {
__asm__ __volatile__ (" foo %0, %1" : "=m" (*p) : "i" (bit));
}
else {
// Do something else.
}
}
.
.
.
f(3, some_pointer);
.
.
.
Among the versions of GCC that can build the current kernel, will any fail on
this code because the "i" constraint cannot be matched when expanded to RTL?
David Daney
Re: newlib & libgcov
"Bingfeng Mei" <[EMAIL PROTECTED]> writes: > Both -Dinhibit_libc and -DL_gcov are used as shown in our building log > file. I guess -Dinhibit_libc is added because we used newlibc instead > of glibc. I tried to grep these functions in newlibc and didn't find > them. My question is how to enable gcov with newlibc. Do I need to > write my own versions of them? Any suggestion is greatly appreciated. You need to configure with --with-headers so that the headers are used during the build and that inhibit_libc is not defined. I think this is what the crosstool-newlib script does as well. Adam
Re: Resend: [PATCH] [MIPS] Fix asm constraints for 'ins' instructions.
David Daney <[EMAIL PROTECTED]> writes:
> Richard Sandiford wrote:
>> David Daney <[EMAIL PROTECTED]> writes:
>>> Ralf Baechle wrote:
On Wed, Jun 11, 2008 at 10:04:25AM -0700, David Daney wrote:
> The third operand to 'ins' must be a constant int, not a register.
>
> Signed-off-by: David Daney <[EMAIL PROTECTED]>
> ---
> include/asm-mips/bitops.h |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/asm-mips/bitops.h b/include/asm-mips/bitops.h
> index 6427247..9a7274b 100644
> --- a/include/asm-mips/bitops.h
> +++ b/include/asm-mips/bitops.h
> @@ -82,7 +82,7 @@ static inline void set_bit(unsigned long nr, volatile
> unsigned long *addr)
> "2: b 1b \n"
> " .previous \n"
> : "=&r" (temp), "=m" (*m)
> - : "ir" (bit), "m" (*m), "r" (~0));
> + : "i" (bit), "m" (*m), "r" (~0));
> #endif /* CONFIG_CPU_MIPSR2 */
> } else if (cpu_has_llsc) {
> __asm__ __volatile__(
An old trick to get gcc to do the right thing. Basically at the stage when
gcc is verifying the constraints it may not yet know that it can optimize
things into an "i" argument, so compilation may fail if "r" isn't in the
constraints. However we happen to know that due to the way the code is
written gcc will always be able to make use of the "i" constraint so no
code using "r" should ever be created.
The trick is a bit ugly; I think it was used first in asm-i386/io.h ages
ago
and I would be happy if we could get rid of it without creating new
problems.
Maybe a gcc hacker here can tell more?
>>> It is not nice to lie to GCC.
>>>
>>> CCing GCC and Richard in hopes that a wider audience may shed some light on
>>> the issue.
>>
>> You _might_ be able to use "i#r" instead of "ri", but I wouldn't
>> really recommend it. Even if it works now, I don't think there's
>> any guarantee it will in future.
>>
>> There are tricks you could pull to detect the problem at compile time
>> rather than assembly time, but that's probably not a big win. And again,
>> I wouldn't recommend them.
>>
>> I'm not saying anything you don't know here, but if the argument is
>> always a syntactic constant, the safest bet would be to apply David's
>> patch and also convert the function into a macro. I notice some other
>> ports use macros rather than inline functions here. I assume you've
>> deliberately rejected macros as being too ugly though.
>
> I am still a little unclear on this.
>
> To restate the question:
>
> static inline void f(unsigned nr, unsigned *p)
> {
> unsigned short bit = nr & 5;
>
> if (__builtin_constant_p(bit)) {
> __asm__ __volatile__ (" foo %0, %1" : "=m" (*p) : "i" (bit));
> }
> else {
> // Do something else.
> }
> }
> .
> .
> .
> f(3, some_pointer);
> .
> .
> .
>
> Among the versions of GCC that can build the current kernel, will any
> fail on this code because the "i" constraint cannot be matched when
> expanded to RTL?
Someone will point this out if I don't, so for avoidance of doubt:
this needs to be always_inline. It also isn't guaranteed to work
with "bit" being a separate statement. I'm not truly sure it's
guaranteed to work even with:
__asm__ __volatile__ (" foo %0, %1" : "=m" (*p) : "i" (nr & 5));
but I think we'd try hard to make sure it does.
I think Maciej said that 3.2 was the minimum current version.
Even with those two issues sorted out, I don't think you can
rely on this sort of thing with compilers that used RTL inlining.
(always_inline does go back to 3.2, in case you're wondering.)
Richard
[tuples] API documentation
I just finished going through the API document adding missing content and updating stale information. While there are various aspects of GIMPLE that are not covered in the document, it is probably complete enough for converting/adding gimple code. At the moment I'm wondering what would be the best way to host this documentation. Do we leave it on some web-based form (wiki or google docs)? Do we move it to the source tree as .texi files? I can see advantages to both approaches. Leaving it on the web, makes it easier to edit and evolve. Moving to the source tree makes it easier to version but harder to edit. The document is now linked off of the tuples wiki (http://gcc.gnu.org/wiki/tuples). The direct link is http://docs.google.com/Doc?id=dgfkmttj_107hcr98sg3 I would also appreciate feedback in terms of what is missing and what would be useful to add. Thanks. Diego.
[EMAIL PROTECTED]: Results for 4.4.0 20080612 (experimental) [trunk revision 136692] (GCC) testsuite on m32c-unknown-elf]
I should start posting these to the testing list. Lots of m16c improvements, but some m32c regressions. I haven't tried to diagnose these yet, but if nobody claims it's their fault I will ;-) Anyone know why the regressions happened? DJ --- Start of forwarded message --- Date: Thu, 12 Jun 2008 07:01:34 -0400 From: DJ Delorie <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Results for 4.4.0 20080612 (experimental) [trunk revision 136692] (GCC) testsuite on m32c-unknown-elf gcc result changes... Multilib: m32c-sim/-mcpu=m16c FAIL-PASS: gcc.c-torture/execute/builtins/pr23484-chk.c execution, -O1 FAIL-PASS: gcc.c-torture/execute/builtins/pr23484-chk.c execution, -O2 FAIL-PASS: gcc.c-torture/execute/builtins/pr23484-chk.c execution, -O3 -fomit-frame-pointer FAIL-PASS: gcc.c-torture/execute/builtins/pr23484-chk.c execution, -O3 -g FAIL-PASS: gcc.c-torture/execute/builtins/pr23484-chk.c execution, -Os FAIL-PASS: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -O1 FAIL-PASS: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -O2 FAIL-PASS: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -O3 -fomit-frame-pointer FAIL-PASS: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL-PASS: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL-PASS: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -O3 -g FAIL-PASS: gcc.c-torture/execute/builtins/snprintf-chk.c execution, -Os FAIL-PASS: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -O1 FAIL-PASS: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -O2 FAIL-PASS: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -O3 -fomit-frame-pointer FAIL-PASS: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL-PASS: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL-PASS: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -O3 -g FAIL-PASS: gcc.c-torture/execute/builtins/sprintf-chk.c execution, -Os FAIL-PASS: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O1 FAIL-PASS: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O2 FAIL-PASS: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O3 -fomit-frame-pointer FAIL-PASS: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL-PASS: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL-PASS: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O3 -g FAIL-PASS: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -Os FAIL-PASS: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O1 FAIL-PASS: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O2 FAIL-PASS: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O3 -fomit-frame-pointer FAIL-PASS: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL-PASS: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL-PASS: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -O3 -g FAIL-PASS: gcc.c-torture/execute/builtins/vsprintf-chk.c execution, -Os FAIL-PASS: gcc.c-torture/execute/20030626-2.c execution, -O0 FAIL-PASS: gcc.c-torture/execute/920501-8.c execution, -O0 FAIL-PASS: gcc.c-torture/execute/920501-8.c execution, -O1 FAIL-PASS: gcc.c-torture/execute/920501-8.c execution, -O2 FAIL-PASS: gcc.c-torture/execute/920501-8.c execution, -O3 -fomit-frame-pointer FAIL-PASS: gcc.c-torture/execute/920501-8.c execution, -O3 -g FAIL-PASS: gcc.c-torture/execute/920501-8.c execution, -Os FAIL-PASS: gcc.c-torture/execute/920501-9.c execution, -O0 FAIL-PASS: gcc.c-torture/execute/920501-9.c execution, -O1 FAIL-PASS: gcc.c-torture/execute/920501-9.c execution, -O2 FAIL-PASS: gcc.c-torture/execute/920501-9.c execution, -O3 -fomit-frame-pointer FAIL-PASS: gcc.c-torture/execute/920501-9.c execution, -O3 -g FAIL-PASS: gcc.c-torture/execute/920501-9.c execution, -Os FAIL-PASS: gcc.c-torture/execute/920726-1.c execution, -O0 FAIL-PASS: gcc.c-torture/execute/920726-1.c execution, -O1 FAIL-PASS: gcc.c-torture/execute/920726-1.c execution, -O2 FAIL-PASS: gcc.c-torture/execute/920726-1.c execution, -O3 -fomit-frame-pointer FAIL-PASS: gcc.c-torture/execute/920726-1.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL-PASS: gcc.c-torture/execute/920726-1.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL-PASS: gcc.c-torture/execute/920726-1.c execution, -O3 -g FAIL-PASS: gcc.c-torture/execute/920726-1.c execution, -Os FAIL-PASS: gcc.c-torture/ex
Re: [tuples] API documentation
Diego Novillo <[EMAIL PROTECTED]> writes: > I just finished going through the API document adding missing content > and updating stale information. While there are various aspects of > GIMPLE that are not covered in the document, it is probably complete > enough for converting/adding gimple code. > > At the moment I'm wondering what would be the best way to host this > documentation. Do we leave it on some web-based form (wiki or google > docs)? Do we move it to the source tree as .texi files? > > I can see advantages to both approaches. Leaving it on the web, makes > it easier to edit and evolve. Moving to the source tree makes it > easier to version but harder to edit. I think that when it is reasonably stable it should move into a .texi file in the source code. That is there the gcc internals manual lives. I would not be averse to moving the entire internals manual to the web in some form. But having it in two places does not seem like a good idea to me. Ian
Re: Resend: [PATCH] [MIPS] Fix asm constraints for 'ins' instructions.
Richard Sandiford wrote:
David Daney <[EMAIL PROTECTED]> writes:
Richard Sandiford wrote:
David Daney <[EMAIL PROTECTED]> writes:
Ralf Baechle wrote:
On Wed, Jun 11, 2008 at 10:04:25AM -0700, David Daney wrote:
The third operand to 'ins' must be a constant int, not a register.
Signed-off-by: David Daney <[EMAIL PROTECTED]>
---
include/asm-mips/bitops.h |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-mips/bitops.h b/include/asm-mips/bitops.h
index 6427247..9a7274b 100644
--- a/include/asm-mips/bitops.h
+++ b/include/asm-mips/bitops.h
@@ -82,7 +82,7 @@ static inline void set_bit(unsigned long nr, volatile
unsigned long *addr)
"2:b 1b \n"
" .previous \n"
: "=&r" (temp), "=m" (*m)
- : "ir" (bit), "m" (*m), "r" (~0));
+ : "i" (bit), "m" (*m), "r" (~0));
#endif /* CONFIG_CPU_MIPSR2 */
} else if (cpu_has_llsc) {
__asm__ __volatile__(
An old trick to get gcc to do the right thing. Basically at the stage when
gcc is verifying the constraints it may not yet know that it can optimize
things into an "i" argument, so compilation may fail if "r" isn't in the
constraints. However we happen to know that due to the way the code is
written gcc will always be able to make use of the "i" constraint so no
code using "r" should ever be created.
The trick is a bit ugly; I think it was used first in asm-i386/io.h ages ago
and I would be happy if we could get rid of it without creating new problems.
Maybe a gcc hacker here can tell more?
It is not nice to lie to GCC.
CCing GCC and Richard in hopes that a wider audience may shed some light on the
issue.
You _might_ be able to use "i#r" instead of "ri", but I wouldn't
really recommend it. Even if it works now, I don't think there's
any guarantee it will in future.
There are tricks you could pull to detect the problem at compile time
rather than assembly time, but that's probably not a big win. And again,
I wouldn't recommend them.
I'm not saying anything you don't know here, but if the argument is
always a syntactic constant, the safest bet would be to apply David's
patch and also convert the function into a macro. I notice some other
ports use macros rather than inline functions here. I assume you've
deliberately rejected macros as being too ugly though.
I am still a little unclear on this.
To restate the question:
static inline void f(unsigned nr, unsigned *p)
{
unsigned short bit = nr & 5;
if (__builtin_constant_p(bit)) {
__asm__ __volatile__ (" foo %0, %1" : "=m" (*p) : "i" (bit));
}
else {
// Do something else.
}
}
.
.
.
f(3, some_pointer);
.
.
.
Among the versions of GCC that can build the current kernel, will any
fail on this code because the "i" constraint cannot be matched when
expanded to RTL?
Someone will point this out if I don't, so for avoidance of doubt:
this needs to be always_inline. It also isn't guaranteed to work
with "bit" being a separate statement. I'm not truly sure it's
guaranteed to work even with:
__asm__ __volatile__ (" foo %0, %1" : "=m" (*p) : "i" (nr & 5));
but I think we'd try hard to make sure it does.
I think Maciej said that 3.2 was the minimum current version.
Even with those two issues sorted out, I don't think you can
rely on this sort of thing with compilers that used RTL inlining.
(always_inline does go back to 3.2, in case you're wondering.)
Well I withdraw the patch. With the current kernel code we seem to always get
good code generation. In the event that the compiler tries to put the shift
amount (nr) in a register, the assembler will complain. I don't think it is
possible to generate bad object code, so best to leave it alone.
FYI, the reason that I stumbled on this several weeks ago is that
if(__builtin_constant_p(nr)) in the trunk compiler was generating code for the
asm even though nr was not constant.
David Daney
Re: [lto] function to DECL associations for WPA repackaging
On 2008-06-12, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> I have no idea how to make sure, in whopr, that function x sees foobar if
> you are going to cherry pick the globals also.
I'm not sure I see the problem that you are pointing to. In this program:
int N;
int foobar;
int *bar = &foobar;
int **foo = &bar;
x ()
{
int **x = foo;
return **x;
}
All of 'foobar', 'bar' and 'foo' will be in the list of symbols
referenced by x(). When time comes to emit those symbols,
gimple_referenced_vars(x) will have the set of globals that we are
looking for. Global symbol N will not be in the list, and that's
fine.
Diego.
testsuite location for adding new tests
Hi, As part of our thread safety annotation/analysis effort, we created about 17 new test cases that we would like to add to the gcc testsuite. Should we create a new sub-directory under testsuite/g++.dg (say, for example, g++.dg/thread-ann)? Or should we add them to an existing sub-dir, e.g. testsuite/g++.dg/warn? (Some of the test cases would cause the compiler to emit thread safety warning messages, but some of them are "good" cases that no warning should be generated. So we are not sure if they should all go to g++.dg/warn.) Thanks, Le-chun
gcc-4.3-20080612 is now available
Snapshot gcc-4.3-20080612 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080612/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 136725 You'll find: gcc-4.3-20080612.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20080612.tar.bz2 C front end and core compiler gcc-ada-4.3-20080612.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20080612.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20080612.tar.bz2 C++ front end and runtime gcc-java-4.3-20080612.tar.bz2 Java front end and runtime gcc-objc-4.3-20080612.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20080612.tar.bz2The GCC testsuite Diffs from 4.3-20080605 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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: [lto] function to DECL associations for WPA repackaging
On Thu, Jun 12, 2008 at 4:39 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 2008-06-12, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>
>> I have no idea how to make sure, in whopr, that function x sees foobar if
>> you are going to cherry pick the globals also.
>
> I'm not sure I see the problem that you are pointing to. In this program:
>
> int N;
> int foobar;
> int *bar = &foobar;
> int **foo = &bar;
> x ()
> {
> int **x = foo;
> return **x;
> }
>
> All of 'foobar', 'bar' and 'foo' will be in the list of symbols
> referenced by x().
Why do you think foobar will be in the list?
(I'm just curious, i'm not saying you are wrong).
Constructing static variables in GIMPLE?
Dear mailing list:
I am writing GCC code that constructs GIMPLE (after pass_apply_inline
and before pass_all_optimizations) for a function-level static
variable that gets assigned to and passed to another function. My
problem is that I am getting undefined symbol errors for a renamed
version of the symbol.
I define the variable as below:
--
static tree build_static(tree type, const char* name)
{
tree ret = NULL;
ret = build_decl(VAR_DECL, get_identifier(name), type);
DECL_ARTIFICIAL(ret) = 1; // declared by the compiler
DECL_IGNORED_P(ret) = 1; // no debug info
TREE_READONLY(ret) = 0; // writable
DECL_EXTERNAL(ret) = 0; // defined
TREE_STATIC(ret) = 1; // static
TREE_USED(ret) = 1; // used
DECL_CONTEXT(ret) = cfun->decl;
create_var_ann(ret);
add_referenced_var(ret);
return ret;
}
--
Here's an example where I use this function, and demonstrating how I
use the variable.
--
tree last_p = build_static(long_long_unsigned_type_node, "last_p");
// ...
tree subtraction = build2(MINUS_EXPR, long_long_unsigned_type_node,
end_time, start_time);
build_gimple_modify_stmt(last_p, subtraction);
// ...
tree last_p_temp = create_tmp_var(TREE_TYPE(last_p),
get_name(last_p));
tree last_p_name = make_ssa_name(last_p_temp, NULL);
tree last_p_assignment = build_gimple_modify_stmt(last_p_name,
last_p);
SSA_NAME_DEF_STMT(last_p_name) = last_p_assignment;
--
As seen above, I (try to) respect SSA when reading from this variable,
and when assigning to it (I create an SSA_NAME when using the value,
and assign directly to the VAR_DECL). I'm passing an SSA_NAME to the
function. However, when I compile, I'm getting linker errors of the
form:
--
[...]/test.c:4: undefined reference to `last_p.2610'
--
Oddly, I don't get undefined references for `last_p'; I find it very
odd that it's being renamed. Does anyone know what's going on here?
As always, I welcome corrections to my (admittedly novice-level)
GIMPLE- and SSA-fu.
Thanks for looking at this.
Sincerely,
Sean Callanan
