> On Fri, Feb 14, 2014 at 2:17 AM, Matthew Fortune
> wrote:
> > MIPS is currently evaluating the benefit of using SIMD registers to pass
> vector data by value. It is currently unclear how important it is for vector
> data
> to be passed in SIMD registers. I.e. the need for passing vector data by
On Fri, 14 Feb 2014, Jan Hubicka wrote:
> > > This smells bad, since it is given a canonical type that is after the
> > > structural equivalency merging that ignores BINFOs, so it may be
> > > completely
> > > different class with completely different bases than the original. Bases
> > > are
>
On Sat, 15 Feb 2014, Jan Hubicka wrote:
> > > > This smells bad, since it is given a canonical type that is after the
> > > > structural equivalency merging that ignores BINFOs, so it may be
> > > > completely
> > > > different class with completely different bases than the original.
> > > > Ba
Matthew Fortune writes:
>> Matthew Fortune writes:
>> > I'm still interested in how successfully the MIPS backend is managing
>> > to avoid floating point but I am also convinced there are bugs in
>> > ld.so entry points for MIPS.
>>
>> It uses the standard mechanism to avoid it, which is markin
On Fri, 2014-02-14 at 11:50 -0800, Linus Torvalds wrote:
> On Fri, Feb 14, 2014 at 9:29 AM, Paul E. McKenney
> wrote:
> >
> > Linus, Peter, any objections to marking places where we are relying on
> > ordering from control dependencies against later stores? This approach
> > seems to me to have s
On Fri, 2014-02-14 at 12:02 -0800, Linus Torvalds wrote:
> On Fri, Feb 14, 2014 at 11:50 AM, Linus Torvalds
> wrote:
> >
> > Why are we still discussing this idiocy? It's irrelevant. If the
> > standard really allows random store speculation, the standard doesn't
> > matter, and sane people should
On Fri, 2014-02-14 at 18:44 -0800, Linus Torvalds wrote:
> On Fri, Feb 14, 2014 at 6:08 PM, Paul E. McKenney
> wrote:
> >
> > One way of looking at the discussion between Torvald and myself would be
> > as a seller (Torvald) and a buyer (me) haggling over the fine print in
> > a proposed contract
On Sat, Feb 15, 2014 at 9:45 AM, Torvald Riegel wrote:
>
> I think a major benefit of C11's memory model is that it gives a
> *precise* specification for how a compiler is allowed to optimize.
Clearly it does *not*. This whole discussion is proof of that. It's
not at all clear, and the standard a
Folks,
One of the things that we've been discussing for a while and there are
just too many options out there and none fits exactly what we're
looking for (obviously), is the vectorization control pragmas.
Our initial semantics is working on on a specific loop / lexical block to:
* turn vectoriz
On Sat, Feb 15, 2014 at 9:30 AM, Torvald Riegel wrote:
>
> I think the example is easy to misunderstand, because the context isn't
> clear. Therefore, let me first try to clarify the background.
>
> (1) The abstract machine does not write speculatively.
> (2) Emitting a branch instruction and exe
On Sat, Feb 15, 2014 at 06:56:42PM +, Renato Golin wrote:
> 1. Local pragma (#pragma vectorize), which is losing badly on the
> argument that it's yet-another pragma to do mostly the same thing many
> others do.
>
> 2. Using OMP SIMD pragmas (#pragma simd, #pragma omp simd) which is
> already
On 15 February 2014 19:26, Jakub Jelinek wrote:
> GCC supports #pragma GCC ivdep/#pragma simd/#pragma omp simd, the last one
> can be used without rest of OpenMP by using -fopenmp-simd switch.
Does the simd/omp have control over the tree vectorizer? Or are they
just flags for the omp implementati
Snapshot gcc-4.7-20140215 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20140215/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 2/15/2014 3:36 PM, Renato Golin wrote:
On 15 February 2014 19:26, Jakub Jelinek wrote:
GCC supports #pragma GCC ivdep/#pragma simd/#pragma omp simd, the last one
can be used without rest of OpenMP by using -fopenmp-simd switch.
Does the simd/omp have control over the tree vectorizer? Or ar
On 15 February 2014 22:49, Tim Prince wrote:
> In my experience, the (somewhat complicated) gcc --param options work
> sufficiently well for specification of unrolling.
There is precedent for --param in LLVM, we could go this way, too.
Though, I can't see how it'd be applied to a specific functio
15 matches
Mail list logo
