Hi Martin,
I agree, we need more information from the compiler. Esp. whether the user
specified `-mprefer-avx128` or `-mprefer-vector-width=none/128/256/512`.
OTOH `-msve-vector-bits=N` is reported as __ARM_FEATURE_SVE_BITS. So that's
covered.
Related: PR83875 - because while we're adding thing
Hi Matthias!
> I agree, we need more information from the compiler. Esp. whether the user
> specified `-mprefer-avx128` or `-mprefer-vector-width=none/128/256/512`.
> OTOH `-msve-vector-bits=N` is reported as __ARM_FEATURE_SVE_BITS. So that's
> covered.
Almost ... except that I'd need a platfor
On Wed, May 22, 2019 at 10:36 AM Martin Reinecke
wrote:
>
> Hi Matthias!
>
> > I agree, we need more information from the compiler. Esp. whether the user
> > specified `-mprefer-avx128` or `-mprefer-vector-width=none/128/256/512`.
> > OTOH `-msve-vector-bits=N` is reported as __ARM_FEATURE_SVE_BIT
On 5/22/19 11:17 AM, Richard Biener wrote:
>> Almost ... except that I'd need a platform-agnostic definition. The
>> point is that the code does not care about the underlying hardware at
>> all, only for the vector length supported by it.
>
> And then you run into AVX + SSE vs. AVX2 + SSE case
On Mittwoch, 22. Mai 2019 11:17:57 CEST Richard Biener wrote:
> On Wed, May 22, 2019 at 10:36 AM Martin Reinecke
> wrote:
> > Hi Matthias!
> >
> > > I agree, we need more information from the compiler. Esp. whether the
> > > user
> > > specified `-mprefer-avx128` or `-mprefer-vector-width=none/12
On Mittwoch, 22. Mai 2019 11:27:25 CEST Martin Reinecke wrote:
> Still, I would need a way to determine how long the vectors actually
> are. But it would probably be enough to measure this at runtime then.
FWIW, something that took me way too long to figure out: You can use vector
builtins very c
On 21/05/2019 21:18, Bill Schmidt wrote:
> On 5/21/19 11:47 AM, Martin Sebor wrote:
>> The GCC coding style says to use "floating-point" as an adjective
>> rather than "floating point." After enhancing the -Wformat-diag
>> checker to detect this I found a bunch of uses of the latter, such
>> as in
微1365一09一04255
Hi Uros,
> On 21 May 2019, at 19:36, Uros Bizjak wrote:
>
> On Tue, May 21, 2019 at 6:15 PM Iain Sandoe wrote:
>>
>> It seems to me that (even if it was working “properly”, which it isn't)
>> ‘-mfentry’ would break ABI on Darwin for both 32 and 64b - which require
>> 16byte stack alignment
On 5/22/19 5:19 AM, Richard Earnshaw (lists) wrote:
> On 21/05/2019 21:18, Bill Schmidt wrote:
>> On 5/21/19 11:47 AM, Martin Sebor wrote:
>>> The GCC coding style says to use "floating-point" as an adjective
>>> rather than "floating point." After enhancing the -Wformat-diag
>>> checker to detect
On 22/05/2019 13:17, Bill Schmidt wrote:
> On 5/22/19 5:19 AM, Richard Earnshaw (lists) wrote:
>> On 21/05/2019 21:18, Bill Schmidt wrote:
>>> On 5/21/19 11:47 AM, Martin Sebor wrote:
The GCC coding style says to use "floating-point" as an adjective
rather than "floating point." After en
On 22/05/2019 13:17, Bill Schmidt wrote:
> "We should use floating point."
In fact, since we're compiler folk, we just say it's undefined behaviour
and optimize it to
"."
:-P
R.
The lazy binding code of aarch64 currently only preserves q0-q7 of the
fp registers, but for an SVE call [AAPCS64+SVE] it should preserve p0-p3
and z0-z23, and for an AdvSIMD vector call [VABI64] it should preserve
q0-q23. (Vector calls are extensions of the base PCS [AAPCS64].)
A possible fix is
On 5/22/19 6:27 AM, Richard Earnshaw (lists) wrote:
On 22/05/2019 13:17, Bill Schmidt wrote:
On 5/22/19 5:19 AM, Richard Earnshaw (lists) wrote:
On 21/05/2019 21:18, Bill Schmidt wrote:
On 5/21/19 11:47 AM, Martin Sebor wrote:
The GCC coding style says to use "floating-point" as an adjective
On 5/22/19 9:58 AM, Martin Sebor wrote:
> On 5/22/19 6:27 AM, Richard Earnshaw (lists) wrote:
>> On 22/05/2019 13:17, Bill Schmidt wrote:
>>> On 5/22/19 5:19 AM, Richard Earnshaw (lists) wrote:
On 21/05/2019 21:18, Bill Schmidt wrote:
> On 5/21/19 11:47 AM, Martin Sebor wrote:
>> The G
* Szabolcs Nagy:
> AAELF64: in the Symbol Table section add
>
> st_other Values
> The st_other member of a symbol table entry specifies the symbol's
> visibility in the lowest 2 bits. The top 6 bits are unused in the
> generic ELF ABI [SCO-ELF], and while there are no val
On 22/05/2019 16:06, Florian Weimer wrote:
> * Szabolcs Nagy:
>
>> AAELF64: in the Symbol Table section add
>>
>> st_other Values
>> The st_other member of a symbol table entry specifies the symbol's
>> visibility in the lowest 2 bits. The top 6 bits are unused in the
>> g
* Szabolcs Nagy:
> On 22/05/2019 16:06, Florian Weimer wrote:
>> * Szabolcs Nagy:
>>
>>> AAELF64: in the Symbol Table section add
>>>
>>> st_other Values
>>> The st_other member of a symbol table entry specifies the symbol's
>>> visibility in the lowest 2 bits. The top 6 bits are
On 22/05/2019 16:34, Florian Weimer wrote:
> * Szabolcs Nagy:
>
>> On 22/05/2019 16:06, Florian Weimer wrote:
>>> * Szabolcs Nagy:
>>>
AAELF64: in the Symbol Table section add
st_other Values
The st_other member of a symbol table entry specifies the symbol's
Greetings All,
After getting it some thought I've yet to see any real focus on making the RTL
layers or just the architectural backends parallel in nature. Is there a reason
for this as my assumption is that after reading parts of the x86 and rs6000
backend code it's not needed.
This seems to b
*This note will talk about the 4 major components of the prototype and
explain how they work together. I will be fairly light on detail just
to give an overview, we can delve into whatever details are needed.
- Range-ops : Range operations at the statement level
- GORI - Generates Outgoing Ran
Now that stage 1 has reopened, I’d like to reopen a discussion about the
technology and experiences we have from the Ranger project I brought up
last year. https://gcc.gnu.org/ml/gcc/2018-05/msg00288.html . (The
original wiki pages are now out of date, and I will work on updating
them soon.)
There is a functioning prototype in branch “ssa-range” which is a proof
of concept that the approach is functional as well as quick, and can be
used to answer questions which come up regarding what it can and can’t
do. Our last merge was on April 13th, so it's fairly up to date.
We have imple
We have done extensive performance analysis to help address concerns
about the nature of an on-demand model. LLVM made an attempt at
something similar, but suffered from significant performance issues
they could not solve with their approach. This approach is not the same,
and we have seen no
A primary goal of this approach is to try to pull the various aspects of
VRP apart and make them individually viable so they can be used at
appropriate places as needed. The various components of VRP were
identified as:
- Ranges
- Relational queries
- Equivalencies
- Bitmask tr
25 matches
Mail list logo
