Serializing mixed gimple data from a plugin in LTO?
Hello All,
Let's imagine someone is writing a plugin (or a MELT extension...) which
computes some complex information around gimple in a pass before LTO
serialization and re-uses that information in a later pass after LTO
serialization. A possible way to associate data inside a plugin to some gimples
would be to have hash tables (keys being Gimple, associated value being some
complex information specific to the plugin). The the plugin would compute &
serialize [i.e. write or output] data in a pass before LTO and deserialize
[re-read or input] that data at LTO time.
The writing happens in the write_summary and write_optimization_summary hooks
of struct ipa_opt_pass_d of file tree-pass.h. The reading happens in
read_summary & read_optimization_summary hooks.
But what I cannot understand is how can such a plugin know what are the gimple
involved. Since the plugin needs to persist (i.e. serialize into LTO stream &
de-serialize) an hash table mapping some gimples to its data, the plugin need
to know what gimples are serialized & deserialized, to restore at LTO streaming
read the common gimple pointers (the same gimple pointer should appear in the
function & the hash table)
I would imagine gcc/lto-streamer-out.c would have a plugin hook inside
output_gimple_stmt but this is not the case...
I admit I don't have a clear picture of LTO streams usage (& customization)
from plugins.
Or perhaps it is not possible yet???
Regards.
--
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 mine, sont seulement les miennes} ***
Re: Serializing mixed gimple data from a plugin in LTO?
On Fri, Mar 25, 2011 at 8:37 AM, Basile Starynkevitch
wrote:
> Hello All,
>
> Let's imagine someone is writing a plugin (or a MELT extension...) which
> computes some complex information around gimple in a pass before LTO
> serialization and re-uses that information in a later pass after LTO
> serialization. A possible way to associate data inside a plugin to some
> gimples would be to have hash tables (keys being Gimple, associated value
> being some complex information specific to the plugin). The the plugin would
> compute & serialize [i.e. write or output] data in a pass before LTO and
> deserialize [re-read or input] that data at LTO time.
>
> The writing happens in the write_summary and write_optimization_summary hooks
> of struct ipa_opt_pass_d of file tree-pass.h. The reading happens in
> read_summary & read_optimization_summary hooks.
>
> But what I cannot understand is how can such a plugin know what are the
> gimple involved. Since the plugin needs to persist (i.e. serialize into LTO
> stream & de-serialize) an hash table mapping some gimples to its data, the
> plugin need to know what gimples are serialized & deserialized, to restore at
> LTO streaming read the common gimple pointers (the same gimple pointer should
> appear in the function & the hash table)
>
> I would imagine gcc/lto-streamer-out.c would have a plugin hook inside
> output_gimple_stmt but this is not the case...
>
> I admit I don't have a clear picture of LTO streams usage (& customization)
> from plugins.
> Or perhaps it is not possible yet???
You are not allowed to piggy-back on statements but only global things
like cgraph and varpool. There is no way to transition data from before
LTO to after associated with statements. And there never will be.
Richard.
> Regards.
> --
> 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 mine, sont seulement les miennes} ***
>
Re: [C++0x] Range-based for statements and ADL
On Wed, Mar 23, 2011 at 5:46 PM, Jason Merrill wrote:
> Yep. Here is the wording that we approved today:
[snip]
Nice. Thank you.
But now I'm a bit concerned about the complexity of this issue. Mind
me, I think that this solution is nice, but maybe it is a burden for
library implementors.
Let's say that I want to imitate 'exactly' the behavior of the
range-for, but with a plain old for (there are plenty of reasons for
that):
template void foo(C &c)
{
auto _b = begin(c);
auto _e = end(c);
for (auto _i = _b; _i != _e; ++_i)
{
auto _e = *_i;
//do stuff
}
}
But this will fail sometimes for the reasons stated in N3257. If I
change the first line to:
auto _b = c.begin();
it will fail in a lot of different cases.
So I'm forced to write a pair of functions, let's name them
'range_begin/range_end' with a lot of SFINAE tricks to mimic the
range-for behavior. And there are a lot of subtleties and magic in the
range-for specification that makes that a hard work, if at all
possible.
IMHO, it would be much easier if the standard library provided these
functions for me. Before, I considered that was what
std::begin/std::end did, but now...
--
Rodrigo
Re: [C++0x] Range-based for statements and ADL
On 25 March 2011 10:13, Rodrigo Rivas wrote:
>
> But now I'm a bit concerned about the complexity of this issue. Mind
> me, I think that this solution is nice, but maybe it is a burden for
> library implementors.
>
> Let's say that I want to imitate 'exactly' the behavior of the
> range-for, but with a plain old for (there are plenty of reasons for
> that):
> template void foo(C &c)
> {
> auto _b = begin(c);
> auto _e = end(c);
> for (auto _i = _b; _i != _e; ++_i)
> {
> auto _e = *_i;
> //do stuff
> }
> }
>
> But this will fail sometimes for the reasons stated in N3257. If I
> change the first line to:
> auto _b = c.begin();
> it will fail in a lot of different cases.
> So I'm forced to write a pair of functions, let's name them
> 'range_begin/range_end' with a lot of SFINAE tricks to mimic the
> range-for behavior. And there are a lot of subtleties and magic in the
> range-for specification that makes that a hard work, if at all
> possible.
>
> IMHO, it would be much easier if the standard library provided these
> functions for me. Before, I considered that was what
> std::begin/std::end did, but now...
It's FAR too late - do you want a new standard today or next year?
If you want something that behaves like range-for use range-for.
Or just don't use range-for, it's not essential (given the trouble
it's caused I'd quite happily have lived without it in C++0x!)
Re: [C++0x] Range-based for statements and ADL
On Fri, Mar 25, 2011 at 11:13 AM, Rodrigo Rivas wrote: > On Wed, Mar 23, 2011 at 5:46 PM, Jason Merrill wrote: >> Yep. Here is the wording that we approved today: > [snip] > > Nice. Thank you. > But now I'm a bit concerned about the complexity of this issue. Mind > me, I think that this solution is nice, but maybe it is a burden for > library implementors. > > Let's say that I want to imitate 'exactly' the behavior of the > range-for, but with a plain old for (there are plenty of reasons for > that): I'd be interested to know those reasons. (Not that we're going to change range-based for at this point, but maybe we can have a better understanding of its ramifications.) -- James
Re: [C++0x] Range-based for statements and ADL
On Fri, Mar 25, 2011 at 5:13 AM, Rodrigo Rivas wrote: > On Wed, Mar 23, 2011 at 5:46 PM, Jason Merrill wrote: >> Yep. Here is the wording that we approved today: > [snip] > > Nice. Thank you. > But now I'm a bit concerned about the complexity of this issue. Mind > me, I think that this solution is nice, but maybe it is a burden for > library implementors. > > Let's say that I want to imitate 'exactly' the behavior of the > range-for, but with a plain old for (there are plenty of reasons for > that): troubles are not far when people start wanting C++ to do everything including doing exactly in library what a core language facility was invented to do. IMNSHO, it is almost almost a mistake to take that direction.
Re: Using secondary reload to reload CONST_INT?
Richard Sandiford schrieb: > Georg-Johann Lay writes: >> 1) The internals just mention TARGET_SECONDARY_RELOAD for REG-MEM and >> for REG-REG moves, no word about REG-CONST moves. So is using >> secondary reloads for CONST_INT (or other consts) like outlined >> above a defined use case I can rely on? > > Yeah, it should be. Other targets rely on this too. E.g. MIPS allows > integers to be stored in FPRs as well as GPRs, but you can't load a > symbolic constant directly into an FPR; it has to go through a GPR. > >> 2) The secondary reload hook is always called with >> regclass = GENERAL_REGS, even in cases where the class >> is known to be NO_LD_REGS like, e.g. when preparing arguments >> for a function call. Why this? I would expect to get the smallest >> available regclass. If a reg lies in LD_REGS, a secondary reload >> is not needed, but how can I know if class is always GENERAL_REGS? >> Is it ensured that secondary reload hook gets never called when >> a constraint alternative matches, like "d,i"? > > As far as the last bit goes: once reload has decided that it needs to > reload A into B, it's uses the secondary reload hook (and only that hook) > to decide whether a secondary reload is needed. The movsi constraints > only matter when reloading a pre-reload movsi instruction. Ok, so even if there is an "A,B" alternative (or superset) in respective mov insn, reload will query secondary reload hook. What does "reloading a pre-reload mov instruction" mean? > I think the reason you only ever see GENERAL_REGS being passed in is > because (from a quick look at avr.md) very few non-move patterns use > the "d" and "l" constraints. They all seem to use the "r" constraint. > Thus reloads from those instructions will use GENERAL_REGS rather than > NO_LD_REGS. Thanks for that clarification. I though that when there is a need to do a move, the movXX constraints would apply. "r" is the union of "l" and "d" just for 8- and 16-bit modes. For SI there is reg:SI 14 which spans both "l" (14,15) and "d" (16,17) so that this reg is neither in "l" nor "d" but in "r". So the constraint would have to be "ldr". Unfortunately, the internals doc on constraints are not very comprehensible and there is much space for misunderstanding and speculation on how to apply them correctly. Getting the "big picture" is hardly possible from internals, and diving into reload sources is even worse. So the gaps are filled with intuition, which is often misleading or wrong. Would be great if a reload expert would add a page or so to internals to give comprehensive explanation and overview. > If you want to make reload use NO_LD_REGS for these GENERAL_REGS reloads, > at least when the reloaded value is a constant, then it might be worth > defining TARGET_PREFERRED_RELOAD_CLASS. It's preferred to load constants into LD_REGS, because these regs have instructions to do that. However, LD_REGS are already very busy, and I suspect it is no good idea to increase register pressure on them even more. All in all, I think the changes go to too far. I am not a reload expert, and there is room for improvement without affecting reload. Thanks anyway. >> 3) What is the "unit" of sri->extra_cost? Compared to COST_N_INSNS? >> Or compared to "?" constraint cost? > > I think it's measured in the same units as REGISTER_MOVE_COST. > (2 == a simple register move). > > Richard Johann
Re: [C++0x] Range-based for statements and ADL
On 03/25/2011 11:13 AM, Rodrigo Rivas wrote: Let's say that I want to imitate 'exactly' the behavior of the range-for, but with a plain old for (there are plenty of reasons for that): Note that there was already a special case for arrays. Jason
Re: [C++0x] Range-based for statements and ADL
On Fri, Mar 25, 2011 at 11:52 AM, James Dennett wrote:
> I'd be interested to know those reasons.
Well, maybe not *plenty*, but *some*... Let's say that I have a function:
template void Dump(S &s, const T &t)
{
for (auto i : t)
s.dump(i);
}
Cool!
Now I want to do the following:
template void DumpExtra(S &s, const T &t)
{
auto _b = begin(c);
auto _e = end(c);
for (auto _it = _b; _it != _e; ++_it)
{
auto i = *_it;
if (s.condition(i))
s.dump(i);
else
{
if (++_it == _e)
break;
s.dump2(i, *_it);
}
}
I cannot use the range-for because I increment the iterator. But now
I'm not sure if this may not compile, or worse, may use a different
range definition than the other one!
Disclaimer: the fact that I lack the imagination for a better example
doesn't mean that it will not happen in the real world.
--
Rodrigo
Re: [C++0x] Range-based for statements and ADL
> On 03/25/2011 11:13 AM, Rodrigo Rivas wrote: > Note that there was already a special case for arrays. Yes, but std::begin/std::end are overloaded for arrays also, so the library implementor would get the right behavior for free. They are still vulnerable to the ADL issue, though. -- Rodrigo
Re: Serializing mixed gimple data from a plugin in LTO?
On Fri, Mar 25, 2011 at 06:06, Richard Guenther wrote: > You are not allowed to piggy-back on statements but only global things > like cgraph and varpool. There is no way to transition data from before > LTO to after associated with statements. And there never will be. But one could write out a table indexed by gimple statement uid. That would allow the pass to reconstruct the statement metadata on the way in. Diego.
Re: Serializing mixed gimple data from a plugin in LTO?
On Fri, Mar 25, 2011 at 12:52 PM, Diego Novillo wrote: > On Fri, Mar 25, 2011 at 06:06, Richard Guenther > wrote: > >> You are not allowed to piggy-back on statements but only global things >> like cgraph and varpool. There is no way to transition data from before >> LTO to after associated with statements. And there never will be. > > But one could write out a table indexed by gimple statement uid. That > would allow the pass to reconstruct the statement metadata on the way > in. That's true. You still have to shove your data through WPA stage though (which doesn't have stmts). Richard.
Re: [C++0x] Range-based for statements and ADL
N.B. I'm going to use the term "good old for" instead of "plain old for" ;-)
On 25 March 2011 11:43, Rodrigo Rivas wrote:
> On Fri, Mar 25, 2011 at 11:52 AM, James Dennett
> wrote:
>> I'd be interested to know those reasons.
> Well, maybe not *plenty*, but *some*... Let's say that I have a function:
> template void Dump(S &s, const T &t)
> {
> for (auto i : t)
> s.dump(i);
> }
> Cool!
>
> Now I want to do the following:
> template void DumpExtra(S &s, const T &t)
> {
You need:
using std::begin;
using std::end;
here to emulate the FCD range-for behaviour, so that namespace std is
an associated namespace.
> auto _b = begin(c);
> auto _e = end(c);
> for (auto _it = _b; _it != _e; ++_it)
> {
> auto i = *_it;
> if (s.condition(i))
> s.dump(i);
> else
> {
> if (++_it == _e)
> break;
> s.dump2(i, *_it);
> }
> }
> I cannot use the range-for because I increment the iterator. But now
> I'm not sure if this may not compile, or worse, may use a different
> range definition than the other one!
>
> Disclaimer: the fact that I lack the imagination for a better example
> doesn't mean that it will not happen in the real world.
I might write the loop above to use qualified calls to std::begin and
std::end, and require users of strange types to wrap their range in an
adaptor with begin/end members, so that std::begin and std::end do the
right thing. The adaptor would forward to my::begin/my::end or
whatever you wanted ADL to find.
We're never going to achieve perfection so everything works for all cases.
Re: [C++0x] Range-based for statements and ADL
On Fri, Mar 25, 2011 at 11:27 AM, Jonathan Wakely wrote: > Or just don't use range-for, it's not essential (given the trouble > it's caused I'd quite happily have lived without it in C++0x!) IMO, this goes beyond the syntactic sugar that the range-for provides. It is about specifying a unified 'range' concept. The range-for is just the first, highly visible, user of this implicit specification. -- Rodrigo
Supporting multiple pointer sizes in GCC
Hello, Is it possible to support multiple pointer sizes (e.g. 16bit, 32bit) which can co-exist in single compilation unit? I want to add this support in backend code of a target architecture for C and C++ languages. I referred an old discussion about same topic on following URL: http://gcc.gnu.org/ml/gcc/2006-08/msg00067.html However, even after going through this discussion I am still not very clear about this. Whether it is supported in GCC now? Is there any other architecture which has this feature already implemented? Regards, Jayant Sonar
Re: [C++0x] Range-based for statements and ADL
On 25 March 2011 12:27, Rodrigo Rivas wrote: > > IMO, this goes beyond the syntactic sugar that the range-for provides. > It is about specifying a unified 'range' concept. The range-for is > just the first, highly visible, user of this implicit specification. Yes but it's too late to specify it in C++0x. Boost.Range is the best place to work on that idea at present. If/when it's fully baked I hope we'll see something like that in a future TR or standard.
Re: [C++0x] Range-based for statements and ADL
On Fri, Mar 25, 2011 at 7:27 AM, Rodrigo Rivas wrote: > On Fri, Mar 25, 2011 at 11:27 AM, Jonathan Wakely > wrote: >> Or just don't use range-for, it's not essential (given the trouble >> it's caused I'd quite happily have lived without it in C++0x!) > > IMO, this goes beyond the syntactic sugar that the range-for provides. > It is about specifying a unified 'range' concept. But what is that `unified range concept'? And why do we need it? > The range-for is > just the first, highly visible, user of this implicit specification. Exactly. Which for me means, it must be simple. Simple to learn, simple to use, simple to teach. BTW, if you are trying to change the specification is gcc-patches the appropriate place to discuss that?
Re: [C++0x] Range-based for statements and ADL
On Fri, Mar 25, 2011 at 1:34 PM, Gabriel Dos Reis wrote: > But what is that `unified range concept'? And why do we need it? See Boost.Range for the concept and possibly uses. There has been some discussion to accept it in the standard, IIRC. > Exactly. Which for me means, it must be simple. Simple to learn, > simple to use, simple to teach. The range-for as it is specified in this thread *is* simple to learn use and teach. Not so easy to implement, but not so hard either. I am merely pointing out that strictly emulating the range-for behavior is far from trivial. > BTW, if you are trying to change the specification is gcc-patches > the appropriate place to discuss that? I have no intention to specify anything, I'm just suggesting that it would be nice to have a library function that does this. And this is not gcc-patches@ but gcc@: "Anything relevant to the development or testing of GCC and not covered by other mailing lists is suitable for discussion here." -- Rodrigo
Re: [C++0x] Range-based for statements and ADL
On Fri, Mar 25, 2011 at 1:33 PM, Jonathan Wakely wrote:
> Yes but it's too late to specify it in C++0x.
>
> Boost.Range is the best place to work on that idea at present.
> If/when it's fully baked I hope we'll see something like that in a
> future TR or standard.
Agreed.
But just now, how would you explain if the following to loops behave
differently?
template void foo(T &t)
{
for (auto i : t)
;
for (auto i : boost::any_range(t))
;
}
Because the boost::any_range constructor is unable to replicate the
logic from the range-for?
Sezon Ürünleri, Teslimatta Ödeme seçeneği ile...
Merhaba, Yeni sezon ürünlerimizi incelemenizi rica ederim. Teslimatta ödeme seçeneği başlamıştır. Bilginize. www.eliticgiyim.com ELİT İÇ GİYİM Pazaar Ltd Şti Tarlabaşı Bulvarı No: 117 Daire: 1 Beyoğlu / İstanbul - TÜRKİYE Tel: 0212 2528577 Fax: 0212 2525668 Gsm: 0530 7733170 Powered by Doruk Bilgi Teknolojileri
Re: Second GCC 4.6.0 release candidate is now available
Hi Michael, Thanks for running these. I spent some time this morning looking through the results, they largely look ok though I don't have much perspective on the the objc/ obj-c++ failures. These failures here For v7-a , A9 and Neon - these failures below: > Running target unix > FAIL: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer (test > for excess errors) > UNRESOLVED: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer > compilation failed to produce executable > FAIL: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer > -funroll-loops (test for excess errors) > UNRESOLVED: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer > -funroll-loops compilation failed to produce executable > FAIL: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer > -funroll-all-loops -finline-functions (test for excess errors) > UNRESOLVED: gfortran.dg/array_constructor_11.f90 -O3 -fomit-frame-pointer > -funroll-all-loops -finline-functions compilation failed to produce > executable > FAIL: gfortran.dg/array_constructor_11.f90 -O3 -g (test for excess errors) > UNRESOLVED: gfortran.dg/array_constructor_11.f90 -O3 -g compilation failed > to produce executable > FAIL: gfortran.dg/func_assign_3.f90 -O3 -fomit-frame-pointer (test for > excess errors) > UNRESOLVED: gfortran.dg/func_assign_3.f90 -O3 -fomit-frame-pointer > compilation failed to produce executable > FAIL: gfortran.dg/func_assign_3.f90 -O3 -fomit-frame-pointer -funroll-loops > (test for excess errors) > UNRESOLVED: gfortran.dg/func_assign_3.f90 -O3 -fomit-frame-pointer > -funroll-loops compilation failed to produce executable > FAIL: gfortran.dg/func_assign_3.f90 -O3 -fomit-frame-pointer > -funroll-all-loops -finline-functions (test for excess errors) > UNRESOLVED: gfortran.dg/func_assign_3.f90 -O3 -fomit-frame-pointer > -funroll-all-loops -finline-functions compilation failed to produce > executable > FAIL: gfortran.dg/func_assign_3.f90 -O3 -g (test for excess errors) > UNRESOLVED: gfortran.dg/func_assign_3.f90 -O3 -g compilation failed to > produce executable are caused by a broken assembler. All these tests appear to pass fine in a cross environment on my machine. These all appear to fail because of the assembler failing to assemble something like vmov.i64 d9,#-4294967296 which is vmov.i64 d9,0x and a valid instruction. I think your assembler needs an update Otherwise the testresults for A9 appear to be largely in line with other results. From v5t. > FAIL: gcc.dg/c90-intconst-1.c (internal compiler error) > FAIL: gcc.dg/c90-intconst-1.c (test for excess errors) The c90 testfails in your v5t run appear to be some kind of NFS glitch because the compiler fails to spawn from dejagnu. I tried logging into ursa2 and tried out the same test after fettling with paths etc and it just seemed to work. I'm still looking through the other results but I haven't spotted anything obvious broken yet. cheers Ramana On Thu, Mar 24, 2011 at 9:04 PM, Michael Hope wrote: > On Tue, Mar 22, 2011 at 11:12 AM, Jakub Jelinek wrote: >> A second GCC 4.6.0 release candidate is available at: >> >> ftp://gcc.gnu.org/pub/gcc/snapshots/4.6.0-RC-20110321/ >> >> Please test the tarballs and report any problems to Bugzilla. >> CC me on the bugs if you believe they are regressions from >> previous releases severe enough to block the 4.6.0 release. >> >> If no more blockers appear I'd like to release GCC 4.6.0 >> early next week. > > The RC bootstraps C, C++, Fortran, Obj-C, and Obj-C++ on > ARMv7/Cortex-A9/Thumb-2/NEON, ARMv5T/ARM/softfp, ARMv5T/Thumb/softfp, > and ARMv4T/ARM/softfp. I'm afraid I haven't reviewed the test results > (Richard? Ramana?) > > See: > http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02298.html > http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02391.html > http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02394.html > http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02393.html > > and: > http://builds.linaro.org/toolchain/gcc-4.6.0-RC-20110321/logs/ > > -- Michael >
Re: [C++0x] Range-based for statements and ADL
On 25 March 2011 14:22, Rodrigo Rivas wrote:
> On Fri, Mar 25, 2011 at 1:33 PM, Jonathan Wakely
> wrote:
>> Yes but it's too late to specify it in C++0x.
>>
>> Boost.Range is the best place to work on that idea at present.
>> If/when it's fully baked I hope we'll see something like that in a
>> future TR or standard.
>
> Agreed.
> But just now, how would you explain if the following to loops behave
> differently?
>
> template void foo(T &t)
> {
> for (auto i : t)
> ;
> for (auto i : boost::any_range(t))
> ;
> }
>
> Because the boost::any_range constructor is unable to replicate the
> logic from the range-for?
I would say different behaviour is better than an unpreventable
compiler error, which is what happened when combining range-based for
and Boost.Range a few months ago.
Re: Using secondary reload to reload CONST_INT?
Georg-Johann Lay writes: >>> 2) The secondary reload hook is always called with >>> regclass = GENERAL_REGS, even in cases where the class >>> is known to be NO_LD_REGS like, e.g. when preparing arguments >>> for a function call. Why this? I would expect to get the smallest >>> available regclass. If a reg lies in LD_REGS, a secondary reload >>> is not needed, but how can I know if class is always GENERAL_REGS? >>> Is it ensured that secondary reload hook gets never called when >>> a constraint alternative matches, like "d,i"? >> >> As far as the last bit goes: once reload has decided that it needs to >> reload A into B, it's uses the secondary reload hook (and only that hook) >> to decide whether a secondary reload is needed. The movsi constraints >> only matter when reloading a pre-reload movsi instruction. > > Ok, so even if there is an "A,B" alternative (or superset) in > respective mov insn, reload will query secondary reload hook. > > What does "reloading a pre-reload mov instruction" mean? I just meant a move instruction that existed before reload started. If you have a movsi instruction: (set (reg:SI A) (const_int X)) before reload, then reload will use the movsi constraints to decide how to reload it. But reloads themselves are effectively move "operations" that have yet to be created. This means that there are no instructions for reload to match against. The point of the hooks is to help reload decide how these conceptual move operations should be decomposed into real instructions, and what additional temporary registers are needed for those instructions. >> I think the reason you only ever see GENERAL_REGS being passed in is >> because (from a quick look at avr.md) very few non-move patterns use >> the "d" and "l" constraints. They all seem to use the "r" constraint. >> Thus reloads from those instructions will use GENERAL_REGS rather than >> NO_LD_REGS. > > Thanks for that clarification. I though that when there is a need to > do a move, the movXX constraints would apply. > > "r" is the union of "l" and "d" just for 8- and 16-bit modes. For SI > there is reg:SI 14 which spans both "l" (14,15) and "d" (16,17) so > that this reg is neither in "l" nor "d" but in "r". So the constraint > would have to be "ldr". > > Unfortunately, the internals doc on constraints are not very > comprehensible and there is much space for misunderstanding and > speculation on how to apply them correctly. Using "ldr" over "r" would have no effect. "ldr" is the union of "l", "d" and "r", which as you say is simply "r". >> If you want to make reload use NO_LD_REGS for these GENERAL_REGS reloads, >> at least when the reloaded value is a constant, then it might be worth >> defining TARGET_PREFERRED_RELOAD_CLASS. > > It's preferred to load constants into LD_REGS, because these regs have > instructions to do that. However, LD_REGS are already very busy, and I > suspect it is no good idea to increase register pressure on them even > more. I doubt it, TBH. If reload picks a non-LD_REGS register for a constant reload, won't your secondary reload hook say that an LD_REGS temporary is needed? So you get the LD_REGS register either way. What you're doing by defining TARGET_PREFERRED_RELOAD_CLASS is avoiding the need for both an LD_REGS and a non-LD_REGS register. Richard
Re: Second GCC 4.6.0 release candidate is now available
On Mon, Mar 21, 2011 at 03:12:14PM -0700, Jakub Jelinek wrote: > A second GCC 4.6.0 release candidate is available at: > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.6.0-RC-20110321/ > > Please test the tarballs and report any problems to Bugzilla. > CC me on the bugs if you believe they are regressions from > previous releases severe enough to block the 4.6.0 release. See http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02463.html . There's an ICE for gcc.c-torture/compile/limits-exprparen.c which might be an issue. I think that the others may be due to the ancient version of glibc on RHEL 4 systems, though I haven't confirmed this.
Re: Supporting multiple pointer sizes in GCC
"Jayant R. Sonar" writes: > Is it possible to support multiple pointer sizes (e.g. 16bit, 32bit) > which can co-exist in single compilation unit? > Whether it is supported in GCC now? > Is there any other architecture which has this feature already > implemented? Yes, there are three that I know of - mips64, s390 (tpf), and m32c. Although, these days, you might be better served by looking into the named-address-space stuff instead.
Re: Second GCC 4.6.0 release candidate is now available
On Fri, Mar 25, 2011 at 10:28:33AM -0700, Joe Buck wrote: > On Mon, Mar 21, 2011 at 03:12:14PM -0700, Jakub Jelinek wrote: > > A second GCC 4.6.0 release candidate is available at: > > > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.6.0-RC-20110321/ > > > > Please test the tarballs and report any problems to Bugzilla. > > CC me on the bugs if you believe they are regressions from > > previous releases severe enough to block the 4.6.0 release. > > See http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02463.html . > > There's an ICE for gcc.c-torture/compile/limits-exprparen.c > which might be an issue. I think that the others may be due limits-exprparen.c is http://gcc.gnu.org/PR31827, certainly not a recent regression that should block 4.6.0 release and probably nothing you will encounter in real-world testcases, furthermore for many hosts there is a workaround, just increase ulimit -s limit. Jakub
Re: Supporting multiple pointer sizes in GCC
On Mar 25, 2011, at 1:37 PM, DJ Delorie wrote: > > "Jayant R. Sonar" writes: >> Is it possible to support multiple pointer sizes (e.g. 16bit, 32bit) >> which can co-exist in single compilation unit? >> Whether it is supported in GCC now? >> Is there any other architecture which has this feature already >> implemented? > > Yes, there are three that I know of - mips64, s390 (tpf), and m32c. ? MIPS has two pointer sizes, but a given compilation (gcc invocation) uses only one of them, it comes from the chosen ABI. paul
Re: Second GCC 4.6.0 release candidate is now available
> Hi Michael, > > Thanks for running these. I spent some time this morning looking > through the results, they largely look ok though I don't have much > perspective on the the objc/ obj-c++ failures. I had a quick look at the test results for 4.6.0 under Michael's name on the mailing list. The ObjC failures FAIL: objc.dg-struct-layout-encoding-1/t025_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t027_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t028_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t029_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t030_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t031_main.m execution test are not worrying. These fail on many platforms (where they are marked as xfails). But, in http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02391.html a number of ObjC PCH failures are reported; but then lots of PCH tests in the same report fail for C too, so it doesn't seem to be anything specific to ObjC. So, as far as I can see, ObjC/ObjC++ looks good. :-) Thanks
Re: Using secondary reload to reload CONST_INT?
Richard Sandiford schrieb: Georg-Johann Lay writes: 2) The secondary reload hook is always called with regclass = GENERAL_REGS, even in cases where the class is known to be NO_LD_REGS like, e.g. when preparing arguments for a function call. Why this? I would expect to get the smallest available regclass. If a reg lies in LD_REGS, a secondary reload is not needed, but how can I know if class is always GENERAL_REGS? Is it ensured that secondary reload hook gets never called when a constraint alternative matches, like "d,i"? As far as the last bit goes: once reload has decided that it needs to reload A into B, it's uses the secondary reload hook (and only that hook) to decide whether a secondary reload is needed. The movsi constraints only matter when reloading a pre-reload movsi instruction. Ok, so even if there is an "A,B" alternative (or superset) in respective mov insn, reload will query secondary reload hook. What does "reloading a pre-reload mov instruction" mean? I just meant a move instruction that existed before reload started. If you have a movsi instruction: (set (reg:SI A) (const_int X)) before reload, then reload will use the movsi constraints to decide how to reload it. But reloads themselves are effectively move "operations" that have yet to be created. This means that there are no instructions for reload to match against. The point of the hooks is to help reload decide how these conceptual move operations should be decomposed into real instructions, and what additional temporary registers are needed for those instructions. I think the reason you only ever see GENERAL_REGS being passed in is because (from a quick look at avr.md) very few non-move patterns use the "d" and "l" constraints. They all seem to use the "r" constraint. Thus reloads from those instructions will use GENERAL_REGS rather than NO_LD_REGS. Thanks for that clarification. I though that when there is a need to do a move, the movXX constraints would apply. "r" is the union of "l" and "d" just for 8- and 16-bit modes. For SI there is reg:SI 14 which spans both "l" (14,15) and "d" (16,17) so that this reg is neither in "l" nor "d" but in "r". So the constraint would have to be "ldr". Unfortunately, the internals doc on constraints are not very comprehensible and there is much space for misunderstanding and speculation on how to apply them correctly. Using "ldr" over "r" would have no effect. "ldr" is the union of "l", "d" and "r", which as you say is simply "r". If you want to make reload use NO_LD_REGS for these GENERAL_REGS reloads, at least when the reloaded value is a constant, then it might be worth defining TARGET_PREFERRED_RELOAD_CLASS. It's preferred to load constants into LD_REGS, because these regs have instructions to do that. However, LD_REGS are already very busy, and I suspect it is no good idea to increase register pressure on them even more. I doubt it, TBH. If reload picks a non-LD_REGS register for a constant reload, won't your secondary reload hook say that an LD_REGS temporary is needed? So you get the LD_REGS register either way. What you're doing by defining TARGET_PREFERRED_RELOAD_CLASS is avoiding the need for both an LD_REGS and a non-LD_REGS register. > > Richard > The current implementation does not need an intermediate reg. The asm template saves a QI LD_REG in a temporary reg (r0 which is fixed and designed as temporary reg for purposes like that) and uses that LD_REG to copy the const into the non-LD_REG byte by byte. This takes 10 instructions for an SI constant; to get a const into LD_REG SI just takes 4 instructions, one for each byte. The implementation then hopes that peep2 comes up with a LD_REG clobber reg, and in that case that clobber reg is used to get the constant into the non-LD_REG. The peep2 pattern is similar to the old style input reload with a QI clobber. That way, reload need not to supply a clobber reg. My idea was to supply a QI clobber during reload already, so that the copy to and from the fixed temporary reg could be always avoided. There is no need for SI temporary, just for a QI clobber reg. But it's usesless if there is no way to tell if the actual reg where the value is to be stored is LD_REGS or not. Johann
Re: Supporting multiple pointer sizes in GCC
> ? MIPS has two pointer sizes, but a given compilation (gcc > invocation) uses only one of them, it comes from the chosen ABI. You can still override it with __attribute__((mode(SI))) or __attribute__((mode(DI))) for some configurations.
Re: [C++0x] Range-based for statements and ADL
On Fri, Mar 25, 2011 at 8:56 AM, Rodrigo Rivas wrote: > On Fri, Mar 25, 2011 at 1:34 PM, Gabriel Dos Reis > wrote: >> But what is that `unified range concept'? And why do we need it? > See Boost.Range for the concept and possibly uses. Boost.Range is a library component. > There has been some > discussion to accept it in the standard, IIRC. > >> Exactly. Which for me means, it must be simple. Simple to learn, >> simple to use, simple to teach. > The range-for as it is specified in this thread *is* simple to learn > use and teach. If "as it is specified in this thread" you mean option 5, yes I find it simple, which is why I recommended for my NB within WG21 to support it. If you meant something else, I'm less so sure. > Not so easy to implement, but not so hard either. > I am merely pointing out that strictly emulating the range-for > behavior is far from trivial. > >> BTW, if you are trying to change the specification is gcc-patches >> the appropriate place to discuss that? > I have no intention to specify anything, I'm just suggesting that it > would be nice to have a library function that does this. If you are going to do then you are going to specify that function before you implement it. Are you suggesting that as an ISO C++ library function or a GNU extension? > And this is not gcc-patches@ but gcc@: "Anything relevant to the > development or testing of GCC and not covered by other mailing lists > is suitable for discussion here." you are right this is "gcc@". I am not sure you what you imply by the rest.
Re: [C++0x] Range-based for statements and ADL
On Fri, Mar 25, 2011 at 9:22 AM, Rodrigo Rivas
wrote:
> On Fri, Mar 25, 2011 at 1:33 PM, Jonathan Wakely
> wrote:
>> Yes but it's too late to specify it in C++0x.
>>
>> Boost.Range is the best place to work on that idea at present.
>> If/when it's fully baked I hope we'll see something like that in a
>> future TR or standard.
>
> Agreed.
> But just now, how would you explain if the following to loops behave
> differently?
>
> template void foo(T &t)
> {
> for (auto i : t)
> ;
> for (auto i : boost::any_range(t))
> ;
> }
>
> Because the boost::any_range constructor is unable to replicate the
> logic from the range-for?
>
Why does it need to? And why is that GCC problem, not Boost problem
or ISO C++ problem?
Re: [C++0x] Range-based for statements and ADL
On Fri, Mar 25, 2011 at 7:50 PM, Gabriel Dos Reis
wrote:
> Boost.Range is a library component.
True, but should it ever make its way to the standard library, it
would be good if it is consistent with the 'range' used by the
range-for. If not, we will have two subtly different definitions of
'range' in the language.
> If "as it is specified in this thread" you mean option 5,
Yes. Exactly that.
> If you are going to do then you are going to specify that function
> before you implement it. Are you suggesting that as an ISO C++
> library function or a GNU extension?
Well, I am suggesting a ISO C++ library function with the exact
semantics from option 5:
namespace std {
pair range(T &t);
}
Being IT the same type deduced by the range-for iterator. The return
value would be a pair, being the first value the begin iterator and
the second value the end.
I think that one function returning a pair instead of two functions is
better, as the 'special semantics' of the range-for, as it is in
'Option 5', imply both begin and end together.
>> And this is not gcc-patches@ but gcc@: "Anything relevant to the
>> development or testing of GCC and not covered by other mailing lists
>> is suitable for discussion here."
> you are right this is "gcc@". I am not sure you what you imply by the rest.
I'm merely implying that this list is suitable for this discussion. It
looked like you disagree.
Regards.
--
Rodrigo
Re: [C++0x] Range-based for statements and ADL
On Fri, Mar 25, 2011 at 2:51 PM, Rodrigo Rivas
wrote:
> On Fri, Mar 25, 2011 at 7:50 PM, Gabriel Dos Reis
> wrote:
>> Boost.Range is a library component.
> True, but should it ever make its way to the standard library, it
You were earlier talking about some "unified concept"; weren't you?
Now, it is shifting to library component.
> would be good if it is consistent with the 'range' used by the
> range-for. If not, we will have two subtly different definitions of
> 'range' in the language.
Is that a GCC issue or a C++ issue?
>> If "as it is specified in this thread" you mean option 5,
> Yes. Exactly that.
Option 5 does not say that we have to have a library
that exactly emulates what is in in the core language.
>
>> If you are going to do then you are going to specify that function
>> before you implement it. Are you suggesting that as an ISO C++
>> library function or a GNU extension?
>
> Well, I am suggesting a ISO C++ library function with the exact
> semantics from option 5:
if is an ISO C++ library, then the proper place is a ISO C++ committee forum.
> namespace std {
> pair range(T &t);
> }
> Being IT the same type deduced by the range-for iterator. The return
> value would be a pair, being the first value the begin iterator and
> the second value the end.
> I think that one function returning a pair instead of two functions is
> better, as the 'special semantics' of the range-for, as it is in
> 'Option 5', imply both begin and end together.
>
>>> And this is not gcc-patches@ but gcc@: "Anything relevant to the
>>> development or testing of GCC and not covered by other mailing lists
>>> is suitable for discussion here."
>> you are right this is "gcc@". I am not sure you what you imply by the rest.
> I'm merely implying that this list is suitable for this discussion. It
> looked like you disagree.
yes, I do. Because what you are suggesting is a change to the
the ISO C++ definition. This isn't the proper place for that.
Re: [C++0x] Range-based for statements and ADL
On Fri, Mar 25, 2011 at 9:35 PM, Gabriel Dos Reis wrote: > You were earlier talking about some "unified concept"; weren't you? > Now, it is shifting to library component. With "unified" I meant that the same concept (range) is present both in the core language and the standard library. And that it would be wise that both definitions are the same. > Option 5 does not say that we have to have a library > that exactly emulates what is in in the core language. No it does not. That is why I am proposing, If it said that, I would add nothing. BTW, if that function existed, the natural consequence would be to define the range-for in terms of that function, not to copy-paste the specification. >> I'm merely implying that this list is suitable for this discussion. It >> looked like you disagree. > yes, I do. Because what you are suggesting is a change to the > the ISO C++ definition. This isn't the proper place for that. > if is an ISO C++ library, then the proper place is a ISO C++ committee forum. Yes, but sadly I'm not part of the committee, and since there are people here that are, I find it useful to post my suggestion here. Are you saying that in the GCC mailing lists we should discuss only the use and implementation of the languages, but not their specifications? Even if those specifications are in a draft status? I find that hard quite radical. Regards.
gcc-4.6-20110325 is now available
Snapshot gcc-4.6-20110325 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110325/ 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 171529 You'll find: gcc-4.6-20110325.tar.bz2 Complete GCC (includes all of below) MD5=a195d4e100aa1d86e5619542f04f5516 SHA1=cdae457057220f22e7cc78098445b9f3dd34fa11 gcc-core-4.6-20110325.tar.bz2C front end and core compiler MD5=248d44becf2a44003c6418b34790e991 SHA1=44d90a72938dae3f030e0d9add80d3bc5611c035 gcc-ada-4.6-20110325.tar.bz2 Ada front end and runtime MD5=106270dcc2c39a8885b628999abfc2be SHA1=74f2eeacd4efbc4bf739031b60c07171ff1c1c7f gcc-fortran-4.6-20110325.tar.bz2 Fortran front end and runtime MD5=54d8384ca06094fd22f7916cceef6c2a SHA1=b23551b2733cd7cec32fc99fb1543176102cc064 gcc-g++-4.6-20110325.tar.bz2 C++ front end and runtime MD5=ccf12496a86e8be199f0df921ebda353 SHA1=c7b2e57bc00f00abf7de6260a9c291255fc3819a gcc-go-4.6-20110325.tar.bz2 Go front end and runtime MD5=80a0da1dd520a3248c29264b9bf9eaa5 SHA1=e042b76bfbe2829a552663e4ae75f5d767a843e8 gcc-java-4.6-20110325.tar.bz2Java front end and runtime MD5=847c0a3d625e1b8ef3deb002d80210d9 SHA1=200182e4c46acd50480eba3f93ec0ae641d70a18 gcc-objc-4.6-20110325.tar.bz2Objective-C front end and runtime MD5=7ab165c510808682773d68272f266375 SHA1=64a9f4faa6346087d21cecaba159900e5fd58307 gcc-testsuite-4.6-20110325.tar.bz2 The GCC testsuite MD5=982db8dfa873df61793ecbc1c46ceaf0 SHA1=0f2fbea8de0971744b49aedb6f842f51a3595e5f Diffs from 4.6-20110318 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: [C++0x] Range-based for statements and ADL
On Fri, Mar 25, 2011 at 5:01 PM, Rodrigo Rivas wrote: > On Fri, Mar 25, 2011 at 9:35 PM, Gabriel Dos Reis > wrote: >> You were earlier talking about some "unified concept"; weren't you? >> Now, it is shifting to library component. > > With "unified" I meant that the same concept (range) is present both > in the core language and the standard library. And that it would be > wise that both definitions are the same. I see a core language specification, I see a third party library implementation. I don't see a unified concept. > >> Option 5 does not say that we have to have a library >> that exactly emulates what is in in the core language. > No it does not. That is why I am proposing, If it said that, I would > add nothing. if it would add nothing, then we are in violent agreement that we should not be having the discussion here :-) > BTW, if that function existed, the natural consequence would be to > define the range-for in terms of that function, not to copy-paste the > specification. Ideally, an implementation should just be that: an implementation of a specification, not the specification itself. > >>> I'm merely implying that this list is suitable for this discussion. It >>> looked like you disagree. >> yes, I do. Because what you are suggesting is a change to the >> the ISO C++ definition. This isn't the proper place for that. >> if is an ISO C++ library, then the proper place is a ISO C++ committee forum. > > Yes, but sadly I'm not part of the committee, and since there are > people here that are, I find it useful to post my suggestion here. A better forum is news:comp.std.c++ > Are you saying that in the GCC mailing lists we should discuss only > the use and implementation of the languages, but not their > specifications? I am saying that discussion of the specifications themselves should be conducted in appropriate forum (and I do not believe gcc@ is appropriate forum to discussion range-for specification for itlself), unless, of course, it is the -GCC implementation-= of that specification. I think the original discussion was right on topic, but it diverged into potential modification to the specification itself, at which point it become more appropriate for a different forum. E.g., as far as I understand you were not proposing a GNU extension (I asked that question repeatedly) but rather a potential ISO C++ library extension. > Even if those specifications are in a draft status? Yes -- even more so. In fact by the time were having the discussion today, it was past the status of draft that could be modified without major disruption: the document went into FDIS status. Being in draft status does not magically confer appropriateness for gcc@. > I find that hard quite radical. I'll leave you with that view.
GCC 4.6.1 Status Report (2011-03-26)
Status == GCC 4.6.0 release tarballs have been uploaded to gcc.gnu.org and ftp.gnu.org, the 4.6 branch is open again for commits under the usual release branch rules. I'll announce the release once mirrors had some time to download it. GCC 4.6.1 is planned for roughly late May, unless some unexpected severe bug forces us to release it earlier. Quality Data Priority # Change from Last Report --- --- P10 0 P2 85 + 4 P3 20 + 17 --- --- Total 105 + 21 Previous Report === http://gcc.gnu.org/ml/gcc/2011-03/msg00176.html The next report will be sent by Joseph.
