On 08/23/2013 12:12 AM, Alec Teal wrote:
> http://gcc.gnu.org/wiki/FunctionMultiVersioning
>
> Reported by "kobrien" on the Freenode IRC network, channel #gcc just
> now, I'm just sending the message.
Looking at http://gcc.gnu.org/wiki/RecentChanges shows that the GCC wiki
is being spammed a lot.
Hi Vladimir,
I've been working on code size improvements for mips16 and have been pleased to
see some improvement when switching to use LRA instead of classic reload. At
the same time though I have also seen some differences between reload and LRA
in terms of how efficiently reload registers ar
On 23 August 2013 08:01, Václav Zeman wrote:
> On 08/23/2013 12:12 AM, Alec Teal wrote:
>> http://gcc.gnu.org/wiki/FunctionMultiVersioning
>>
>> Reported by "kobrien" on the Freenode IRC network, channel #gcc just
>> now, I'm just sending the message.
> Looking at http://gcc.gnu.org/wiki/RecentCha
> Roughly. We have 3 directives here,
> #pragma omp target
> #pragma omp target data
> #pragma omp target update
> and all of them have various clauses, some that are allowed at most once
> (e.g. the device clause, if clause) and others that can be used many times
> (the data movement clauses).
>
On Fri, Aug 23, 2013 at 01:28:10PM +0400, Michael V. Zolotukhin wrote:
> Sure, I used '#pragma omp target' just for a simple example. The
> question about '#pragma omp target data' is still open. As far as I
> understand, all three of the pragmas could require data marshalling (but
> not necessar
Jakub, Richard, Uday,
Thanks for your answers.
On 15 Aug 20:59, Richard Biener wrote:
> Alternatively you make lto-wrapper aware of this which means that WPA stage
> would emit extra partitions that it marks for lto-wrapper.
>
> That sounds better than another plugin to me. Of course WPA time m
On Fri, Aug 23, 2013 at 02:55:27PM +0400, Ilya Verbin wrote:
> I'm trying to implement the approach with modified lto-wrapper.
> Suppose we have a bytecode of the routine foo, streamed during ompexp pass
> into some section, say .gnu.omptarget_foo.
> In function lto.c:do_whole_program_analysis() a
Wei Mi wrote:
>For the following case:
>
>float total = 0.2;
>
>int main() {
> int i;
>
> for (i = 0; i < 10; i++) {
> total += i;
> }
>
> return total == 0.3;
>}
>
>The gcc assembly of its kernel loop is:
>
>.L3:
> movaps %xmm0, %xmm1
>.L2:
> cvtsi2ss%eax, %xmm0
>
Xinliang David Li wrote:
>Interesting idea!
In the past have already arranged for re-use of the epilogue loop and the
scalar loop, so the situation was even worse.
Note that re-use prevents complete peeling of the epilogue which is often
profitable. Combining the prologue will introduce a mis
Ilya Verbin wrote:
>Jakub, Richard, Uday,
>Thanks for your answers.
>
>On 15 Aug 20:59, Richard Biener wrote:
>> Alternatively you make lto-wrapper aware of this which means that WPA
>stage would emit extra partitions that it marks for lto-wrapper.
>>
>> That sounds better than another plugin to
On Fri, Aug 23, 2013 at 02:24:42PM +0200, Richard Biener wrote:
> >As far as I understood, in addition to the bytecode of foo, we should
> >also stream extra symtab_nodes, and read them somewhere in
> >lto-cgraph.c:input_symtab().
> >This means we should maintain 2 symtabs inside WPA stage - origin
On Fri, Aug 23, 2013 at 02:16:35PM +0200, Richard Biener wrote:
> Xinliang David Li wrote:
> >Interesting idea!
>
> In the past have already arranged for re-use of the epilogue loop and the
> scalar loop, so the situation was even worse.
>
> Note that re-use prevents complete peeling of the epi
>> Looking at http://gcc.gnu.org/wiki/RecentChanges shows that the GCC wiki
>> is being spammed a lot. Somebody should employ some kind of spam protection.
>
> The attack is still ongoing, CC'ing overseers
In fact the spam level on the wiki has been rather high for some time
now, but since yesterd
Hi -
> > Looking at http://gcc.gnu.org/wiki/RecentChanges shows that the GCC wiki
> > is being spammed a lot. Somebody should employ some kind of spam protection.
Several other sourceware-hosted moin wikis have adopted a group-ACL-based
protection, which has eliminated the problem. This involves
On Fri, Aug 23, 2013 at 5:16 AM, Richard Biener
wrote:
> Xinliang David Li wrote:
>>Interesting idea!
>
> In the past have already arranged for re-use of the epilogue loop and the
> scalar loop, so the situation was even worse.
>
> Note that re-use prevents complete peeling of the epilogue which
On 23 August 2013 15:44, Frank Ch. Eigler wrote:
> Hi -
>
>> > Looking at http://gcc.gnu.org/wiki/RecentChanges shows that the GCC wiki
>> > is being spammed a lot. Somebody should employ some kind of spam
>> > protection.
>
> Several other sourceware-hosted moin wikis have adopted a group-ACL-bas
On 23 August 2013 16:04, Jonathan Wakely wrote:
> On 23 August 2013 15:44, Frank Ch. Eigler wrote:
>> Hi -
>>
>>> > Looking at http://gcc.gnu.org/wiki/RecentChanges shows that the GCC wiki
>>> > is being spammed a lot. Somebody should employ some kind of spam
>>> > protection.
>>
>> Several other
Hi -
On Fri, Aug 23, 2013 at 04:06:22PM +0100, Jonathan Wakely wrote:
> [...]
> (Assuming we want to go down the ACL route.)
Done! :-)
> > Is there an easy way to revert a spam change to a page? I don't see one.
> Doh, found it in the "more actions" dropdown.
(It's only accessible there to "adm
> The single call approach would just be passed array of control structures
> that would describe each of the MAP clauses, and you'd simply loop over
> them; the standard requires that if some object is already mapped into the
> device, then nothing is performed (well, target update is an exception
On 23 August 2013 16:25, Frank Ch. Eigler wrote:
> Hi -
>
> On Fri, Aug 23, 2013 at 04:06:22PM +0100, Jonathan Wakely wrote:
>> [...]
>> (Assuming we want to go down the ACL route.)
>
> Done! :-)
Thanks.
I've reverted or deleted all the spam I could find (and that you
hadn't already done) and hav
On Fri, Aug 23, 2013 at 07:30:52PM +0400, Michael V. Zolotukhin wrote:
> That makes sense. We could maintain a vector of descriptors for each
> encountered MAP clause and push to and pop from it when needed (when
> e.g. new mapping is encountered inside 'pragma omp target data'). The
> desciptor
On 23 Aug 13:17, Jakub Jelinek wrote:
> I don't think we should stream into more than one target section.
> There should be just .gnu.target_lto section (or whatever other suitable
> name) and should stream into it:
> 1) all functions and variables with "omp declare target" attribute
> 2) the outli
On Fri, Aug 23, 2013 at 09:15:14PM +0400, Ilya Verbin wrote:
> On 23 Aug 13:17, Jakub Jelinek wrote:
> > I don't think we should stream into more than one target section.
> > There should be just .gnu.target_lto section (or whatever other suitable
> > name) and should stream into it:
> > 1) all fun
Thanks Richard. Yes, without that restriction, the number of
partitions in the partition map will be increased somewhat. But I
think it may not increase a lot for 2 reasons. 1. usually coalesce
list is not a very big list and only the vars in that list will be
added to conflict graph. It already re
Wei Mi wrote:
>Thanks Richard. Yes, without that restriction, the number of
>partitions in the partition map will be increased somewhat. But I
>think it may not increase a lot for 2 reasons. 1. usually coalesce
>list is not a very big list and only the vars in that list will be
>added to conflict
25 matches
Mail list logo
