Displaying 5 results from an estimated 5 matches for "autovec".
2013 Oct 24
1
[LLVMdev] [OT] ARMv8 (AArch64) server
...ch64.
Thanks David (I'm aware of this)
My goal is to connect with other ARM partners who are interested in
server/HPC. If they are targeting a server market (128 cores @3Ghz?) -
I'd like to discuss if HPC is on their roadmap - if not - why not (such
as llvm missing Fortran support, simd autovec, loop optimizations.. etc)
(I do have an ARM contact, but this seemed easier and likely to be
caught by an engineer)
2019 Mar 08
2
Scalable Vector Types in IR - Next Steps?
Hi folks,
We seem to be converging on how the representation of scalable vectors
will be implemented in IR, and we also have support for such vectors
in the AArch64 back-end. We're also fresh out of the release process
and have a good number of months to hash out potential problems until
next release. What are the next steps to get this merged into trunk?
Given this is a major change to IR,
2006 Oct 31
0
4970475 There should be a stackdepth equivalent for userland
Author: ahl
Repository: /hg/zfs-crypto/gate
Revision: a2677fc0a5fb6895ed56fc4698646ece44978a48
Log message:
4970475 There should be a stackdepth equivalent for userland
5084954 value of dip can be incorrect in autovec
6181505 dtrace sysinfo:::modload probe does not fire when using ''modload''
6265417 schedctl-yield isn''t listed in sdt_subr.c
6272558 gcc and dtrace don''t get along
6276101 dtrace -G behaves strangely with multiple scripts
6284880 intrstat can leak dynamic variable...
2011 Jan 06
0
[LLVMdev] Proposal: Generic auto-vectorization and parallelization approach for LLVM and Polly
...] for gcc seems
> to taking similar approach for auto-vectorization).
This is just historical. Sebastian is planning to couple them a lot
closer. Graphite and auto parallelization/vectorization are not yet
playing well together, even if Sebastian made some huge progress with
Graphite<->Autovec interaction.
> That means Polly (Or other similar framework) should perform necessary
> code transform, then just generates the sequential code, and provides
> necessary parallelism information (These information could be encoded
> as metadata just like TBAA), then the later passes can...
2011 Jan 06
3
[LLVMdev] Proposal: Generic auto-vectorization and parallelization approach for LLVM and Polly
Hi,
I just have a detail look at the code of Polly[1], it seems that Polly
start to support some basic auto-parallelization stuffs. I have some
idea to improve the current auto-vectorization and parallelization
approach in Polly.
The main idea is, we separate the transform passes and codegen passes
for auto-parallelization and vectorization (Graphite[2] for gcc seems
to taking similar approach