> Oh and I see a case where we want to remove byteswaps at IPA level. If
> we can see the variable value does not escape.
That should be relatively easily doable, although I'm a little skeptical of
its practical usefulness.
--
Eric Botcazou
On 2015.06.06 at 18:52 -0400, Aldy Hernandez wrote:
> On 06/06/2015 05:47 PM, Aldy Hernandez wrote:
> > On 06/06/2015 03:33 PM, Jan Hubicka wrote:
> >> Aldy,
> >> also at PPC64le LTO bootstrap (at gcc112) dies with:
> >> ^
> >> 0x104ae8f7 check_die
> >> ../../gcc/dwarf2out.c:5715
> >
> > H
> How is this represented in DWARF?
This is not represented on the branch, because this cannot be done in pure
DWARF. DW_AT_endianity only applies to base types or stand-alone objects and
we would need it for DW_TAG_member (and even DW_TAG_array_type in Ada). But
this could easily be implemen
On Tue, Jun 09, 2015 at 12:17:49PM +0200, Eric Botcazou wrote:
> > How is this represented in DWARF?
>
> This is not represented on the branch, because this cannot be done in pure
> DWARF. DW_AT_endianity only applies to base types or stand-alone objects and
> we would need it for DW_TAG_member
On Tue, Jun 9, 2015 at 12:33 PM, Jakub Jelinek wrote:
> On Tue, Jun 09, 2015 at 12:17:49PM +0200, Eric Botcazou wrote:
>> > How is this represented in DWARF?
>>
>> This is not represented on the branch, because this cannot be done in pure
>> DWARF. DW_AT_endianity only applies to base types or st
> What's the reason to not expose the byte swapping operations earlier, like
> on GIMPLE? (or even on GENERIC?)
That would be too heavy, every load and store in GENERIC/GIMPLE would have an
associated byte swapping operation, although you don't know if they will be
needed in the end. For examp
> Anyway, the DWARF standard doesn't forbid using it on other kinds of DIEs
> and I think emitting it on DW_TAG_member would be natural.
Agreed.
> Not sure why you would want it on DW_TAG_array_type, the endianity for
> arrays should be specified on the element type, shouldn't it?
For the C fami
On Tue, Jun 9, 2015 at 12:39 PM, Eric Botcazou wrote:
>> What's the reason to not expose the byte swapping operations earlier, like
>> on GIMPLE? (or even on GENERIC?)
>
> That would be too heavy, every load and store in GENERIC/GIMPLE would have an
> associated byte swapping operation, although
> Yes, but I'd expect them to be optimized away (well, hopefully).
OK, but you cannot reasonably expose everything in GENERIC/GIMPLE, for example
the mask-and-shift operations to extract bitfields in reverse SSO, only the
RTL expander has the (quite complex) logic and I doubt you want to teach t
On Tue, Jun 9, 2015 at 1:12 PM, Eric Botcazou wrote:
>> Yes, but I'd expect them to be optimized away (well, hopefully).
>
> OK, but you cannot reasonably expose everything in GENERIC/GIMPLE, for example
> the mask-and-shift operations to extract bitfields in reverse SSO, only the
> RTL expander h
> On Jun 9, 2015, at 7:53 PM, Richard Biener wrote:
>
> On Tue, Jun 9, 2015 at 1:12 PM, Eric Botcazou wrote:
>>> Yes, but I'd expect them to be optimized away (well, hopefully).
>>
>> OK, but you cannot reasonably expose everything in GENERIC/GIMPLE, for
>> example
>> the mask-and-shift op
On 06/04/2015 09:15 AM, Ondřej Bílka wrote:
> On Thu, May 28, 2015 at 05:37:53PM +0200, Andreas Krebbel wrote:
>> On 05/28/2015 11:16 AM, Maxim Kuvyrkov wrote:
On May 28, 2015, at 11:59 AM, Richard Biener
wrote:
>> ...
Maybe follow s390 -mhotpatch instead?
>>>
>>> Regarding impleme
> > As I am bit concerned with performance why require nops there? Add a
> > byte count number >= requested thats boundary of next instruction. When
> > lifepatching for return you need to copy this followed by jump back to next
> > instruction. Then gcc could fill that with instructions that don't
> Why would you want to support this on bitfields ... (/me runs away).
This was the only supported case in the original specification. :-)
--
Eric Botcazou
> Because some folks don't want to audit their code to where to add byteswaps.
> I am serious people have legacy big-endian code they want to run little
> endian. There is a reason this is around in the first place. Developers are
> lazy.
That's a little rough, but essentially correct in our exper
Snapshot gcc-5-20150609 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150609/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
Hi!
Funny that I a) had come across the same issue mentioned below, and then
b) today, while searching for something else in my mail archive, stumbled
over this (unanswered) email. ;-)
On Wed, 27 Aug 2014 20:29:17 +0200, Basile Starynkevitch
wrote:
> When I compile some file (precisely, the gc
17 matches
Mail list logo
