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
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
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
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 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 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
> 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
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
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
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 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
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
>> 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
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
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
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
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
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
>
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
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 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
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).
>
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 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.
25 matches
Mail list logo
