Greetings All,
I am dealing with compile optimization comparison between arm64 and intel
platform, with g++ (version 4.9.4).
Compile the following c++ code,
uint32 Witness::getEntityVolatileDataUpdateFlags(Entity* otherEntity)
{
uint32 flags = UPDATE_FLAG_NULL;
if (otherEntit
On Tue, 18 Dec 2018, Jeff Law wrote:
> On 12/18/18 8:36 AM, Richard Biener wrote:
> >
> > Hi,
> >
> > in the past weeks I've been looking into prototyping both spectre V1
> > (speculative array bound bypass) diagnostics and mitigation in an
> > architecture independent manner to assess feasabil
On Tue, 18 Dec 2018, Richard Earnshaw (lists) wrote:
> On 18/12/2018 15:36, Richard Biener wrote:
> >
> > Hi,
> >
> > in the past weeks I've been looking into prototyping both spectre V1
> > (speculative array bound bypass) diagnostics and mitigation in an
> > architecture independent manner to
* Richard Biener:
> The cost is probably target dependent - on x86 it's simply a $fs based
> load/store.
Do you need to reserve something in the TCB for this?
Thanks,
Florian
On Wed, 19 Dec 2018, Florian Weimer wrote:
> * Richard Biener:
>
> > The cost is probably target dependent - on x86 it's simply a $fs based
> > load/store.
>
> Do you need to reserve something in the TCB for this?
No idea. But I figured using TLS with the patch only works when
optimizing and n
Hi!
On Wed, 19 Dec 2018 00:24:00 +0100, I wrote:
> OpenACC 2.6 adds a new clause to the "host_data" construct:
> 2.8.3. "if_present clause". Gergő (in CC) is working on that.
>
> When an 'if_present' clause appears on the directive, the compiler
> will only change the address of any vari
On 19/12/18 09:10, Tangnianyao (ICT) wrote:
> Greetings All,
> I am dealing with compile optimization comparison between arm64 and intel
> platform, with g++ (version 4.9.4).
>
> Compile the following c++ code,
>
> uint32 Witness::getEntityVolatileDataUpdateFlags(Entity* otherEntity)
> {
>
* Richard Biener:
> On Wed, 19 Dec 2018, Florian Weimer wrote:
>
>> * Richard Biener:
>>
>> > The cost is probably target dependent - on x86 it's simply a $fs based
>> > load/store.
>>
>> Do you need to reserve something in the TCB for this?
>
> No idea. But I figured using TLS with the patch o
On Wed, Dec 19, 2018 at 01:46:06PM +0100, Thomas Schwinge wrote:
> > Or, I had the idea that we could avoid that, instead continue using
> > "GOMP_MAP_USE_DEVICE_PTR", and transmit the "if_present" flag through the
> > "int device" argument of "GOACC_data_start" (making sure that old
> > executable
On Wed, 19 Dec 2018, Florian Weimer wrote:
> * Richard Biener:
>
> > On Wed, 19 Dec 2018, Florian Weimer wrote:
> >
> >> * Richard Biener:
> >>
> >> > The cost is probably target dependent - on x86 it's simply a $fs based
> >> > load/store.
> >>
> >> Do you need to reserve something in the TCB
Hi Jakub!
On Wed, 19 Dec 2018 14:38:38 +0100, Jakub Jelinek wrote:
> On Wed, Dec 19, 2018 at 01:46:06PM +0100, Thomas Schwinge wrote:
> > > Or, I had the idea that we could avoid that, instead continue using
> > > "GOMP_MAP_USE_DEVICE_PTR", and transmit the "if_present" flag through the
> > > "in
* Richard Biener:
> Sure, if we'd ever deploy this in production placing this in the
> TCB for glibc targets might be beneifical. But as said the
> current implementation was just an experiment intended to be
> maximum portable. I suppose the dynamic loader takes care
> of initializing the TCB d
On Wed, Dec 19, 2018 at 02:59:54PM +0100, Thomas Schwinge wrote:
> Right. For OpenACC, there's no "device" clause, so we only ever passed
> in "GOMP_DEVICE_ICV" (default), or "GOMP_DEVICE_HOST_FALLBACK" ("if
> (false)" clause). Therefore, the libgomp "resolve_legacy_flags" function
> added to mak
On Wed, Dec 19, 2018 at 03:03:42PM +0100, Jakub Jelinek wrote:
> On Wed, Dec 19, 2018 at 02:59:54PM +0100, Thomas Schwinge wrote:
> > Right. For OpenACC, there's no "device" clause, so we only ever passed
> > in "GOMP_DEVICE_ICV" (default), or "GOMP_DEVICE_HOST_FALLBACK" ("if
> > (false)" clause).
On 12/19/18 7:59 AM, Florian Weimer wrote:
> * Richard Biener:
>
>> Sure, if we'd ever deploy this in production placing this in the
>> TCB for glibc targets might be beneifical. But as said the
>> current implementation was just an experiment intended to be
>> maximum portable. I suppose the dy
On 19/12/2018 11:25, Richard Biener wrote:
> On Tue, 18 Dec 2018, Richard Earnshaw (lists) wrote:
>
>> On 18/12/2018 15:36, Richard Biener wrote:
>>>
>>> Hi,
>>>
>>> in the past weeks I've been looking into prototyping both spectre V1
>>> (speculative array bound bypass) diagnostics and mitigatio
* Peter Bergner:
> On 12/19/18 7:59 AM, Florian Weimer wrote:
>> * Richard Biener:
>>
>>> Sure, if we'd ever deploy this in production placing this in the
>>> TCB for glibc targets might be beneifical. But as said the
>>> current implementation was just an experiment intended to be
>>> maximum p
On Wed, 19 Dec 2018, Florian Weimer wrote:
> * Peter Bergner:
>
> > On 12/19/18 7:59 AM, Florian Weimer wrote:
> >> * Richard Biener:
> >>
> >>> Sure, if we'd ever deploy this in production placing this in the
> >>> TCB for glibc targets might be beneifical. But as said the
> >>> current implem
On Wed, 19 Dec 2018, Richard Earnshaw (lists) wrote:
> On 19/12/2018 11:25, Richard Biener wrote:
> > On Tue, 18 Dec 2018, Richard Earnshaw (lists) wrote:
> >
> >> On 18/12/2018 15:36, Richard Biener wrote:
> >>>
> >>> Hi,
> >>>
> >>> in the past weeks I've been looking into prototyping both spec
On 19/12/2018 17:17, Richard Biener wrote:
> On Wed, 19 Dec 2018, Florian Weimer wrote:
>
>> * Peter Bergner:
>>
>>> On 12/19/18 7:59 AM, Florian Weimer wrote:
* Richard Biener:
> Sure, if we'd ever deploy this in production placing this in the
> TCB for glibc targets might be be
On Wed, 19 Dec 2018, Richard Earnshaw (lists) wrote:
> On 19/12/2018 17:17, Richard Biener wrote:
> > On Wed, 19 Dec 2018, Florian Weimer wrote:
> >
> >> * Peter Bergner:
> >>
> >>> On 12/19/18 7:59 AM, Florian Weimer wrote:
> * Richard Biener:
>
> > Sure, if we'd ever deploy this i
Hi Jakub!
On Wed, 19 Dec 2018 15:18:12 +0100, Jakub Jelinek wrote:
> On Wed, Dec 19, 2018 at 03:03:42PM +0100, Jakub Jelinek wrote:
> > On Wed, Dec 19, 2018 at 02:59:54PM +0100, Thomas Schwinge wrote:
> > > Right. For OpenACC, there's no "device" clause, so we only ever passed
> > > in "GOMP_DEV
22 matches
Mail list logo