On 11/10/2019 00:08, Ramana Radhakrishnan wrote:
On Thu, Oct 10, 2019 at 7:06 PM Richard Sandiford
wrote:
Wilco Dijkstra writes:
ping
Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
bitfields by their declared type, which results in better codegeneration on
practical
On Thu, Oct 10, 2019 at 8:06 PM Richard Sandiford
wrote:
>
> Wilco Dijkstra writes:
> > ping
> >
> > Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
> > bitfields by their declared type, which results in better codegeneration on
> > practically
> > any target.
>
> The name
On Thu, Oct 10, 2019 at 7:06 PM Richard Sandiford
wrote:
>
> Wilco Dijkstra writes:
> > ping
> >
> > Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
> > bitfields by their declared type, which results in better codegeneration on
> > practically
> > any target.
>
> The name
Wilco Dijkstra writes:
> ping
>
> Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
> bitfields by their declared type, which results in better codegeneration on
> practically
> any target.
The name is confusing, but the documentation looks accurate to me:
Define this m
ping
Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
bitfields by their declared type, which results in better codegeneration on
practically
any target.
I'm thinking we should completely remove all trace of SLOW_BYTE_ACCESS
from GCC as it's confusing and useless.
OK for c
On 16/05/18 14:56, Wilco Dijkstra wrote:
> Richard Earnshaw wrote:
>
Which doesn't appear to have been approved. Did you follow up with Jeff?
>>>
>>> I'll get back to that one at some point - it'll take some time to agree on
>>> a way
>>> forward with the callback.
>>>
>>> Wilco
>>>
Richard Earnshaw wrote:
>>> Which doesn't appear to have been approved. Did you follow up with Jeff?
>>
>> I'll get back to that one at some point - it'll take some time to agree on a
>> way
>> forward with the callback.
>>
>> Wilco
>>
>>
>
> So it seems to me that this should then be q
On 15/05/18 17:58, Wilco Dijkstra wrote:
> Hi,
>
>> Which doesn't appear to have been approved. Did you follow up with Jeff?
>
> I'll get back to that one at some point - it'll take some time to agree on a
> way
> forward with the callback.
>
> Wilco
>
>
So it seems to me that this shou
Hi,
> Which doesn't appear to have been approved. Did you follow up with Jeff?
I'll get back to that one at some point - it'll take some time to agree on a way
forward with the callback.
Wilco
On 15/05/18 17:01, Wilco Dijkstra wrote:
> Hi,
>
>> I see nothing about you addressing James' comment from 17th November...
>
> I addressed that in a separate patch, see
> https://patchwork.ozlabs.org/patch/839126/
>
> Wilco
>
Which doesn't appear to have been approved. Did you follow up wi
Hi,
> I see nothing about you addressing James' comment from 17th November...
I addressed that in a separate patch, see
https://patchwork.ozlabs.org/patch/839126/
Wilco
On 15/05/18 14:24, Wilco Dijkstra wrote:
>
> ping
>
>
I see nothing about you addressing James' comment from 17th November...
>
>
> From: Wilco Dijkstra
> Sent: 17 November 2017 15:21
> To: GCC Patches
> Cc: nd
> Subject: [PATCH][AArch64] Set SLOW_BYTE_ACCESS
>
>
> Contrary to all docum
ping
From: Wilco Dijkstra
Sent: 17 November 2017 15:21
To: GCC Patches
Cc: nd
Subject: [PATCH][AArch64] Set SLOW_BYTE_ACCESS
Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
bitfields by their declared type, which results in better codegeneration on
practically
any t
On Fri, Nov 17, 2017 at 03:21:31PM +, Wilco Dijkstra wrote:
> Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
> bitfields by their declared type, which results in better codegeneration on
> practically
> any target.
>
> I'm thinking we should completely remove all trace
14 matches
Mail list logo
