interest for ARM/thumb multiversionning ?
Hi Ramana, Richard
After playing with the attritute ((target ("[thumb,arm]")), during the
pending review, I added the "default" selector to neutralize
-mflip-thumb for the setjmp/longjmp based tests.
I was wondering it there would be an interest leverage on this to
implement multiprocessing, like on the x86 ?
something that would allow (from the x86 doc)
__attribute__ ((target ("default")))
int foo ()
{
asm("...");
return 0;
}
__attribute__ ((target ("thumb")))
int foo ()
{
asm("...");
}
int main ()
{
int (*p)() = &foo;
assert ((*p) () == foo ());
return 0;
}
I had initially not planned to do it, but this is a simple extension of
the attribute target, if someone find a use for this I can implement it
on the fly.
Best Regards,
Christian
Bootstrap configuration for hppa-linux-gnu ?
Hi all, I'm trying to run a bootstrap on a 64-bit hppa-linux-gnu but am getting an error when building libgcc: /usr/include/features.h:374:25: fatal error: sys/cdefs.h: No such file or directory This suggests to me that it's a problem with multilibs. I configured the build with --disable-multiarch --enable-languages=c,c++,fortran. Is there anything else that's usually added to bootstrap on hppa-linux-gnu? Thanks, Kyrill
Re: Bootstrap configuration for hppa-linux-gnu ?
On 2015-04-29, at 4:25 AM, Kyrill Tkachov wrote: > I'm trying to run a bootstrap on a 64-bit hppa-linux-gnu but am getting > an error when building libgcc: > /usr/include/features.h:374:25: fatal error: sys/cdefs.h: No such file or > directory As Helge mentioned, it is not possible to do a 64-bit bootstrap on hppa-linux-gnu since there is no glibc or kernel support for 64-bit runtime. The 64-bit compiler is built as a cross and just used to build 64-bit kernels. 32-bit bootstrap should work fine. "Full" 64-bit support is only available on hpux11. Dave -- John David Anglin dave.ang...@bell.net
gcc 4.9.3 schedule
What is the current schedule for the gcc 4.9.3 maintenance release? Isn't it due this month? Jack
Re: interest for ARM/thumb multiversionning ?
On 29/04/2015 09:24, Christian Bruel wrote:
Hi Ramana, Richard
After playing with the attritute ((target ("[thumb,arm]")), during the
pending review, I added the "default" selector to neutralize
-mflip-thumb for the setjmp/longjmp based tests.
I was wondering it there would be an interest leverage on this to
implement multiprocessing, like on the x86 ?
You mean multiversioning ? How would the dispatcher work in this case ?
Ramana
something that would allow (from the x86 doc)
__attribute__ ((target ("default")))
int foo ()
{
asm("...");
return 0;
}
__attribute__ ((target ("thumb")))
int foo ()
{
asm("...");
}
int main ()
{
int (*p)() = &foo;
assert ((*p) () == foo ());
return 0;
}
I had initially not planned to do it, but this is a simple extension of
the attribute target, if someone find a use for this I can implement it
on the fly.
Best Regards,
Christian
Re: dom1 prevents vectorization via partial loop peeling?
Richard Biener wrote: Well. In this case we hit /* If one of the loop header's edge is an exit edge then do not apply if-conversion. */ FOR_EACH_EDGE (e, ei, loop->header->succs) if (loop_exit_edge_p (loop, e)) return false; which is simply because even after if-conversion we'll at least end up with a non-empty latch block which is what the vectorizer doesn't support. DOM rotated the loop into this non-canonical form. Running loop header copying again would probably undo this. Indeed - header copying causes the loop to be if-converted, and then actually vectorized, too. (Well, I had to make do_while_loop_p a bit more aggressive in saying things weren't do-while loops.) I merely moved pass_ch to immediately after pass_dominator, a few stages later; I have also tried cloning it, but do you foresee any problems with just moving it? (It passes bootstrap, I'm running the full testsuite atm). Cheers, Alan
Re: dom1 prevents vectorization via partial loop peeling?
On 04/28/2015 08:36 AM, Alan Lawrence wrote: Ah, yes, I'd not realized this was connected to the jump-threading issue, but I see that now. As you say, the best heuristics are unclear, and I'm not keen on trying *too hard* to predict what later phases will/won't do or do/don't want...maybe if there are simple heuristics that work, but I would aim more at making later phases work with what(ever) they might get??? Yea, in various places we do try and "predict" what form will be best for later passes, but it's rarely the best way to do things. One (horrible) possibility that I will just throw out (and then duck), is to do something akin to tree-if-conversion's "gimple_build_call_internal (IFN_LOOP_VECTORIZED, " ... It's not as terrible as you might think. The ability to present two forms to the vectorizer has a variety of uses. The one thought we've never explored was re-rolling that first iteration back into the loop in the vectorizer. Yeah, there is that ;). So besides trying to partially-peel the next N iterations, the other approach - that strikes me as sanest - is to finish (fully-)peeling off the first iteration, and then to vectorize from then on. WHich is better may depend on a variety of factors. Complexity of the loop, the iteration space, etc. etc. I suspect it's not terrible to unpeel -- there's two parts. One recognizing particular patterns in the CFG that come from the partial peeling, then detecting that two blocks are still essentially the same, except for the control flow bits at the end of the block. whereas with rerolling ;)...is there perhaps some reasonable way to keep markers around to make the rerolling approach more feasible??? I suspect (but certainly haven't really investigated) that the CFG will have tell-tale signs and that we then look at the key blocks. Jeff
gcc-4.9-20150429 is now available
Snapshot gcc-4.9-20150429 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20150429/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 222597 You'll find: gcc-4.9-20150429.tar.bz2 Complete GCC MD5=3e85701dbe1dd4e0e8f66c9a15d4a0f6 SHA1=ffbfd47b51b6ca5a4599b0cae214afb9c8a8e2ac Diffs from 4.9-20150422 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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: interest for ARM/thumb multiversionning ?
On 04/29/2015 05:36 PM, Ramana Radhakrishnan wrote:
>
>
> On 29/04/2015 09:24, Christian Bruel wrote:
>> Hi Ramana, Richard
>>
>> After playing with the attritute ((target ("[thumb,arm]")), during the
>> pending review, I added the "default" selector to neutralize
>> -mflip-thumb for the setjmp/longjmp based tests.
>>
>> I was wondering it there would be an interest leverage on this to
>> implement multiprocessing, like on the x86 ?
>>
>
> You mean multiversioning ? How would the dispatcher work in this case ?
not sure what you mean, the fonction's name will need to be mangled with
the target specialization. The dispatching would be made based on the
caller mode.
Could it be also a direction to help LTOization with the proper FPU
flags (follow bz target/65837) given at link time.
My concern is that this is limited to C++ for x86. I haven't checked the
details, just ideas.
Cheers
Christian
> Ramana
>
>> something that would allow (from the x86 doc)
>>
>> __attribute__ ((target ("default")))
>> int foo ()
>> {
>>asm("...");
>> return 0;
>> }
>>
>> __attribute__ ((target ("thumb")))
>> int foo ()
>> {
>>asm("...");
>> }
>>
>> int main ()
>> {
>> int (*p)() = &foo;
>> assert ((*p) () == foo ());
>> return 0;
>> }
>>
>> I had initially not planned to do it, but this is a simple extension of
>> the attribute target, if someone find a use for this I can implement it
>> on the fly.
>>
>> Best Regards,
>>
>> Christian
>>
