On Tue, Jul 21, 2020 at 11:25 PM Shuai Wang via Gcc wrote:
>
> Hello,
>
> I am currently trying to migrate a gcc plugin that has been well developed
> for x86 code to ARM platform (for arm-none-eabi-gcc).
>
> Currently I did the following steps:
>
> 1. write a hello world program t.c
>
> 2. compil
On Tue, 2020-07-21 at 22:49 +, Gary Oblock via Gcc wrote:
> Some background:
>
> This is in the dreaded structure reorganization optimization that I'm
> working on. It's running at LTRANS time with '-flto-partition=one'.
>
> My issues in order of importance are:
>
> 1) In gimple-ssa.h, the e
Hey Andrew,
Thanks a lot for getting back to me. No I am not. Let me clarify the
context here:
1. On my Ubuntu (x86-64 version), I use x86 gcc (version 10.0) to
compile this plugin, and test this plugin on various programs' GIMPLE code
during its compilation with x86 gcc (version 10.0).
2. Then,
On 21.07.2020 20:04, Florian Weimer wrote:
> * Premachandra Mallappa:
>
>> [AMD Public Use]
>>
>> Hi Floarian,
>>
>>> I'm including a proposal for the levels below. I use single letters for
>>> them, but I expect that the concrete implementation of this proposal will
>>> use
>>> names like “x8
On Wed, Jul 22, 2020 at 12:45 AM Shuai Wang wrote:
>
> Hey Andrew,
>
> Thanks a lot for getting back to me. No I am not. Let me clarify the context
> here:
>
> 1. On my Ubuntu (x86-64 version), I use x86 gcc (version 10.0) to compile
> this plugin, and test this plugin on various programs' GIMPL
* Dongsheng Song:
> I fully agree these names (100/101, A/B/C/D) are not very intuitive, I
> recommend using isa tags by year (e.g. x64_2010, x64_2014) like the
> python's platform tags (e.g. manylinux2010, manylinux2014).
I started out with a year number, but that was before the was Level A.
Too
On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc wrote:
>
> * Dongsheng Song:
>
> > I fully agree these names (100/101, A/B/C/D) are not very intuitive, I
> > recommend using isa tags by year (e.g. x64_2010, x64_2014) like the
> > python's platform tags (e.g. manylinux2010, manylinux2014).
On Wed, Jul 22, 2020 at 12:51 AM Gary Oblock via Gcc wrote:
>
> Some background:
>
> This is in the dreaded structure reorganization optimization that I'm
> working on. It's running at LTRANS time with '-flto-partition=one'.
>
> My issues in order of importance are:
>
> 1) In gimple-ssa.h, the equ
* Richard Biener:
> On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc
> wrote:
>>
>> * Dongsheng Song:
>>
>> > I fully agree these names (100/101, A/B/C/D) are not very intuitive, I
>> > recommend using isa tags by year (e.g. x64_2010, x64_2014) like the
>> > python's platform tags (e.g. m
* Jan Beulich:
> On 21.07.2020 20:04, Florian Weimer wrote:
>> * Premachandra Mallappa:
>>
>>> [AMD Public Use]
>>>
>>> Hi Floarian,
>>>
I'm including a proposal for the levels below. I use single letters for
them, but I expect that the concrete implementation of this proposal will
>
Dear Andrew,
Thanks a lot. Let me make sure I understand the entire picture here. So
basically on my Ubuntu 18.04 x86 machine, I use:
1. gcc (version 10.0; x86) to compile arm-none-eabi-gcc.
2. And also use gcc (version 10.0; x86) to compile the plugin; I tested a
number of x86 applications and
On 22.07.2020 12:34, Florian Weimer wrote:
> The remaining issue is the - vs _ issue. I think GCC currently uses
> “x86-64” in places that are not part of identifiers or target triplets.
> Richard mentioned “x86_64-” as a potential choice. Would it be too
> awkward to have ”-march=x86_64-…”?
Per
On Wed, Jul 22, 2020 at 12:16 PM Florian Weimer wrote:
>
> * Richard Biener:
>
> > On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc
> > wrote:
> >>
> >> * Dongsheng Song:
> >>
> >> > I fully agree these names (100/101, A/B/C/D) are not very intuitive, I
> >> > recommend using isa tags by
On Wed, Jul 22, 2020 at 6:50 AM Richard Biener via Libc-alpha
wrote:
>
> On Wed, Jul 22, 2020 at 12:16 PM Florian Weimer wrote:
> >
> > * Richard Biener:
> >
> > > On Wed, Jul 22, 2020 at 10:58 AM Florian Weimer via Gcc
> > > wrote:
> > >>
> > >> * Dongsheng Song:
> > >>
> > >> > I fully agree
[AMD Public Use]
> That's deliberate, so that we can use the same x86-* names for 32-bit library
> selection (once we define matching micro-architecture levels there).
Understood.
> If numbers are out, what should we use instead?
> x86-sse4, x86-avx2, x86-avx512? Would that work?
Yes please,
David,
Note, for the first explanation, this is the hash table for the default defs
and not
some private pass specific table so I'm not directly touching it in way.
However, that
doesn't mean some other common or not so common function I'm invoking has
the side effect of doing this in some patho
Richard,
I was really hopeful about your suggestions but I went over my code and
anything that modified anything had a cfun_push and cfun_pop associated with it.
Also, enabling the extra annotations didn't make a difference.
I'm thinking a wolf fence test that scans for malformed default_def has
Richard,
My wolf fence failed to detect an issue at the end of my pass
so I'm now hunting for a problem I caused in a following pass.
Your thoughts?
Gary
- Wolf Fence Follows -
int
wf_func ( tree *slot, tree *dummy)
{
tree t_val = *slot;
gcc_assert( t_val->ssa_name.var);
return 0;
On Thu, Jul 23, 2020 at 5:32 AM Gary Oblock wrote:
>
> Richard,
>
> My wolf fence failed to detect an issue at the end of my pass
> so I'm now hunting for a problem I caused in a following pass.
>
> Your thoughts?
Sorry - I'd look at the IL after your pass for obvious mistakes.
All default defs n
A problem that I keep running into is functions defined headers, but used in
sources files that are compiled with different CPU feature flags (for runtime
CPU feature selection).
We know to make sure the functions are inlinable and their address never
taken, but of course in debug builds they a
20 matches
Mail list logo
