similar to: [LLVMdev] Loop alignment

Displaying 20 results from an estimated 40000 matches similar to: "[LLVMdev] Loop alignment"

2009 Jun 17
0
[LLVMdev] Loop alignment
Asm printer. Evan On Jun 16, 2009, at 2:52 PM, David Greene wrote: > For the X86 target, where is the code that spits out > alignment directives and/or code for loops as determined by the > LoopAligner pass? > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu
2009 Jun 17
2
[LLVMdev] Loop alignment
On Wednesday 17 June 2009 00:11, Evan Cheng wrote: > Asm printer. Yes, but where? I can't find it. What do I need to search for? -Dave
2009 Jun 17
0
[LLVMdev] Loop alignment
> On Wednesday 17 June 2009 00:11, Evan Cheng wrote: >> Asm printer. > > Yes, but where? I can't find it. What do I need to > search for? ViewVC is helpful :- http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/AsmPrinter/ Look at the X86IntelAsmPrinter.cpp file for code outputting the align, if its not there it maybe in the X86AsmPrinter.cpp file, meaning
2008 May 23
2
[LLVMdev] SSE intrinsic alignment bug?
Yep, I'm fixing it (and others) now. Good catch. Evan On May 22, 2008, at 4:59 PM, Dan Gohman wrote: > > On May 22, 2008, at 4:24 PM, Nicolas Capens wrote: >> >> >> Since I’m fairly new to LLVM I’m not entirely sure if this is really >> a bug or something I’m not doing correctly, or whether it’s already >> being addressed. The following thread appears to
2008 May 23
0
[LLVMdev] SSE intrinsic alignment bug?
Fixed. Evan On May 22, 2008, at 5:02 PM, Evan Cheng wrote: > Yep, I'm fixing it (and others) now. Good catch. > > Evan > > On May 22, 2008, at 4:59 PM, Dan Gohman wrote: > >> >> On May 22, 2008, at 4:24 PM, Nicolas Capens wrote: >>> >>> >>> Since I’m fairly new to LLVM I’m not entirely sure if this is really >>> a bug or
2008 Nov 22
2
[LLVMdev] Does current LLVM target-independent code generator supports my strange chip?
I have 24-bit integer operations as well as 24-bit floating point (s7.16) operations. The H/W supports load/store instructions, however, they does suggest us not to use these load/store instructions besides debugging purpose. That is to say, you can imagine we don't have load/store instructions, we don't have memory, we just have registers. I will run OpenGL shading laugnage programs on
2008 Nov 20
0
[LLVMdev] Does current LLVM target-independent code generator supports my strange chip?
This is similar to ATI's R300/R420 pixel shaders. I'm familiar with this hardware, but not really an LLVM expert (working on a code generator myself, but learning as I go). Do you have 24-bit integer operations, or just floating point? What about load/store? Are you looking to run large C programs with complex data structures, or just comparatively simple math functions (i.e. a
2008 Jan 23
2
[LLVMdev] LiveInterval Splitting & SubRegisters
On Wednesday 23 January 2008 02:01, Evan Cheng wrote: > On Jan 22, 2008, at 12:23 PM, David Greene wrote: > > Evan, > > > > Can you explain the basic mechanics of the live interval splitting > > code? > > Is it all in LiveIntervalAnalysis.cpp under addIntervalsForSpills > > and child > > routines? What is it trying to do? > > It's splitting
2008 Nov 20
4
[LLVMdev] Does current LLVM target-independent code generator supports my strange chip?
Because each channel contains 24-bit, so.. what is the llvm::SimpleValueType I should use for each channel? the current llvm::SimpleValueType contains i1, i8, i16, i32, i64, f32, f64, f80, none of them are fit one channel (24-bit). I think I can use i32 or f32 to represent each 24-bit channel, if the runtime result of some machine instructions exceeds 23-bit (1 bit is for sign), then it is an
2008 Jan 25
0
[LLVMdev] LiveInterval Splitting & SubRegisters
On Jan 23, 2008, at 2:40 PM, David Greene <dag at cray.com> wrote: > On Wednesday 23 January 2008 02:01, Evan Cheng wrote: >> On Jan 22, 2008, at 12:23 PM, David Greene wrote: >>> Evan, >>> >>> Can you explain the basic mechanics of the live interval splitting >>> code? >>> Is it all in LiveIntervalAnalysis.cpp under
2007 Oct 19
0
[LLVMdev] movaps being generated despite alignment 1 being specified
On Oct 18, 2007, at 1:52 PM, Chuck Rose III wrote: > > Here are the instructions for evaluateDependents. The JITter > hasn’t compiled foo yet. What’s confusing to me is why did my > movups suddenly become a movaps? All the stores and loads have > align 1 on them. Hi Chuck, I believe this is a bug but am unable to reproduce it with the test case you've provided. I
2007 Oct 18
3
[LLVMdev] movaps being generated despite alignment 1 being specified
Hello LLVMers, High order bit: Presence of a called function is causing a store on an unrelated vector to generate an aligned store rather an unaligned one despite unaligned store being indicated in the associated StoreInst. Details: I pulled down the latest source, so this is something I'm finding with the current LLVM. I'm hoping you'll have an idea what's
2008 Nov 22
0
[LLVMdev] Does current LLVM target-independent code generator supports my strange chip?
On Nov 22, 2008, at 11:03 AM, Wei wrote: > I have 24-bit integer operations as well as 24-bit floating point > (s7.16) operations. > > The H/W supports load/store instructions, however, they does suggest > us not to use these load/store instructions besides debugging purpose. > That is to say, you can imagine we don't have load/store instructions, > we don't have
2013 Dec 10
5
[LLVMdev] ARM Integrated Assembler
Hi Jim/Evan, We had this discussion last year, and I think it's time we revisited this issue again. Many of us (Linaro, ARM, CodeAurora) have been using the ARM integrated assembler for compiling large projects, the test-suite, buildbots, and there seem to be no bug pending on them, with the obscure cases being a few unsupported directives, some of which are already being implemented, while
2008 Nov 24
2
[LLVMdev] Does current LLVM target-independent code generator supports my strange chip?
> The machines I worked with didn't support any integer ops, but GLSL > let us get by with "emulated" 16 bit integers (storing and operating > on them as floating point; divides required truncation after the op - > that sort of thing). Although my platform indeed supports integer operations, however, it only supports integer +,-,*, not /. The document says if I need to
2016 May 28
5
CentOS 6.8 Apache-2.2.15-53 re-write question
I was wondering if somebody could help me with an Apache re-write rule. Apparently CentOS 6.8 is running apache-2.2.15-53. I am trying to redirect all pages except for two pages. The apache rewrite directives in the httpd config are: RewriteEngine on RewriteCond %{REQUEST_URI}!^/test/ RewriteCond %{REQUEST_URI}!^/my-folder/ RewriteRule (.*) http://www.newdomain.com/$1 [R=301,L] These commands
2009 Feb 02
2
[LLVMdev] undefs in phis
On Feb 2, 2009, at 12:12 PM, David Greene wrote: > On Monday 02 February 2009 13:14, Evan Cheng wrote: > >> I am sorry I don't really follow it. Is this what you are describing? >> >> %v1177 = undef >> ... >> loop: >> ... >> %v1176 = op ... >> = %v1177 >> %v1177 = %v1176 >> jmp loop >> >> Why is not
2009 Feb 02
2
[LLVMdev] undefs in phis
On Feb 2, 2009, at 1:05 PM, David Greene wrote: > On Monday 02 February 2009 14:29, Evan Cheng wrote: >> On Feb 2, 2009, at 12:12 PM, David Greene wrote: >>> On Monday 02 February 2009 13:14, Evan Cheng wrote: >>>> I am sorry I don't really follow it. Is this what you are >>>> describing? >>>> >>>> %v1177 = undef
2011 Oct 07
6
[LLVMdev] Enhancing TableGen
Evan Cheng <evan.cheng at apple.com> writes: > David, we cannot accept the 'multidef' keyword. Please revert it. Working on it now. > We appreciate you thinking ahead about MIC, but we are against the > massive refactoring and complicated abstraction scheme. We'll never > accept those patches. How about a less massive and complicated scheme? I think we can make
2009 Apr 16
2
[LLVMdev] Using CallingConvLower in ARM target
After wasting an inordinate amount of time trying to get test-suite to run on arm-apple-darwin so I could reproduce your results, attached is a patch that fixes the small copy&paste error of having 8-byte alignment for stack-allocated f64s instead of the proper 4-byte. I've updated the patch to the top of trunk changes as well. deep On Fri, Feb 27, 2009 at 8:31 PM, Sandeep Patel