similar to: [LLVMdev] DAGCombiner: (S|U)REM

Displaying 20 results from an estimated 6000 matches similar to: "[LLVMdev] DAGCombiner: (S|U)REM"

2007 Jun 19
2
[LLVMdev] DAGCombiner: (S|U)REM
On Mon, 18 Jun 2007, Chris Lattner wrote: > On Thu, 14 Jun 2007, Dietmar Ebner wrote: >> currently, the DAGCombiner unconditionally converts >> (DAGCombiner::visit(U|S)REM) expressions of the form X % C for constants >> C into X-X/C*C. this makes sense in certain cases where the div/mul >> logic will simplify X/C*X but is counterproductive in general, >>
2007 Jun 19
0
[LLVMdev] DAGCombiner: (S|U)REM
On Thu, 14 Jun 2007, Dietmar Ebner wrote: > currently, the DAGCombiner unconditionally converts > (DAGCombiner::visit(U|S)REM) expressions of the form X % C for constants > C into X-X/C*C. this makes sense in certain cases where the div/mul > logic will simplify X/C*X but is counterproductive in general, > especially if the multiply is expensive. also, this doesn't allow >
2007 Jun 19
0
[LLVMdev] DAGCombiner: (S|U)REM
hi, thanks for your answer. On Mon, 2007-06-18 at 23:25 -0700, Chris Lattner wrote: > On Mon, 18 Jun 2007, Chris Lattner wrote: > > On Thu, 14 Jun 2007, Dietmar Ebner wrote: > >> currently, the DAGCombiner unconditionally converts > >> (DAGCombiner::visit(U|S)REM) expressions of the form X % C for constants > >> C into X-X/C*C. this makes sense in certain
2008 Mar 25
3
[LLVMdev] Whole-function isel
Chris, Chris Lattner wrote: > I would love to see any progress in this area. It is clearly an > important thing to tackle, and it is blocking other interesting > improvements in the code generator. It would also allow us to > eliminate a significant amount of weirdness that exists to hack around > this (e.g. switch lowering). we've been working on a whole-function
2008 Mar 31
2
[LLVMdev] Whole-function isel
Evan Cheng wrote: > That's unfortunate. What kind of licensing issues are there? i've talked to our supporting company and they agreed to release the code to interested parties. it's not a copyleft license but the code can be used freely for private and research purposes. be warned that the code is merely a prototype implementation and not ready for inclusion in LLVM. it also
2008 Mar 25
0
[LLVMdev] Whole-function isel
On Mar 25, 2008, at 9:40 AM, Dietmar Ebner wrote: > Chris, > > Chris Lattner wrote: >> I would love to see any progress in this area. It is clearly an >> important thing to tackle, and it is blocking other interesting >> improvements in the code generator. It would also allow us to >> eliminate a significant amount of weirdness that exists to hack >>
2007 Mar 12
1
[LLVMdev] llvm-gcc compile failure on darwin8.8
hello, upgrading llvm-gcc4 from 1.9 release to trunk caused the following build failure for me on darwin: build/genattrtab /Users/ebner/dev/opt/llvm-gcc-svn/gcc/config/i386/ i386.md > tmp-attrtab.c genattrtab: Automaton `ppro_load': Insn `ppro_fmov_XF_load' will never be issued genattrtab: Automaton `ppro_load': Insn `ppro_sse_icvt_SF' will never be issued genattrtab:
2007 Oct 20
2
[LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
hi, Dale Johannesen wrote: > On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote: >> i'm trying to make some experiments with the ARM backend (llvm 2.1) >> and >> therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. >> >> however, the llvm-gcc frontend seems to cause troubles with single >> precision floating point values, i.e., they are
2007 Oct 22
2
[LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
On Oct 22, 2007, at 2:08 AM, Dietmar Ebner wrote: > hi, > > i've got some more things to note. first, the issue is not related to > x86_64 being the host machine - it also happens on i686/linux. > > next, i think (one of) the problem(s) is the use of > [HOST_]WORDS_BIG_ENDIAN instead of [HOST_]FLOAT_WORDS_BIG_ENDIAN in > llvm-convert.cpp (see patch below). > >
2007 Oct 19
3
[LLVMdev] troubles with llvm-gcc 4.0 and APFloat on X86_64
hi, i'm trying to make some experiments with the ARM backend (llvm 2.1) and therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. however, the llvm-gcc frontend seems to cause troubles with single precision floating point values, i.e., they are not converted correctly to the particular target format (double precision works as expected). it seems the problem is related to
2007 Feb 13
6
[LLVMdev] Software Pipelineing | Embedded C Extensions
hello, we're considering LLVM as an excellent framework for a compiler backend for a novel dsp architecture based on vliw principles that is still under development. in this context, two students at our institute are particularly interested in the following projects: I) software pipelining apparently [1], there has been already an remarkable amount of work done by tanya lattner
2009 Mar 12
5
[LLVMdev] Consumer ARM platform suitable for LLVM development?
On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote: > The problem I've had is building an LLVM cross-compiler from Linux/ > x86 to Linux/ARM (as has another llvm-dev poster). Someone > mentioned to me off-list that he managed to get it to build, but I > haven't been able to reproduce the build using his instructions > (I'll post my results in another thread).
2007 Mar 07
2
[LLVMdev] predicated execution
hi, we're trying to come up with a static compiler based on llvm for a 4- way vliw architecture with full support for predicated execution. a distinguishing feature is the omission of flag registers. instead, conditions can be paired with a particular instruction within the same bundle. a performance critical issue will be proper use of predicated execution. if-conversion can either
2007 Feb 14
2
[LLVMdev] Software Pipelineing | Embedded C Extensions
Pertti, On Feb 13, 2007, at 7:34 PM, Pertti Kellomäki wrote: > Dietmar Ebner wrote: >> most of the work seems to be done in an architecture dependent, >> very low- >> level IR. are there any efforts to generalize architecture >> independent portions >> of the code. >> any comments on this are very appreciated. > > We are in a similar
2007 May 30
2
[LLVMdev] wrong codegen
hi, the current release_20 branch seems to miscompile the following reduced testcase (not target architecture specific): #define UInt16 unsigned short #define UInt8 unsigned char UInt8 foo(UInt16 a) { return (UInt8)(((a >> 10) & 1) << 1); } it - misleadingly - optimizes the expression to something like (undef & 2). I guess the problem is related to the DAG combiner but I
2009 Mar 11
0
[LLVMdev] Consumer ARM platform suitable for LLVM development?
On Wed, Mar 11, 2009 at 3:21 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > Now that I have HLVM up and running on x86 and x64 I am interested in > testing > it out on an ARM in preparation for their imminent world domination. I > believe LLVM already has excellent support for the ARM thanks to Apple's > ARM-based products. However, I'd really like an ARM-based
2009 Mar 12
0
[LLVMdev] Consumer ARM platform suitable for LLVM development?
On Thu, Mar 12, 2009 at 6:17 AM, Dietmar Ebner <ebner at complang.tuwien.ac.at>wrote: > On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote: > > The problem I've had is building an LLVM cross-compiler from Linux/ > > x86 to Linux/ARM (as has another llvm-dev poster). Someone > > mentioned to me off-list that he managed to get it to build, but I > > haven't
2007 Oct 22
1
[LLVMdev] cross compiling for arm-softfloat-linux-gnu (was troubles with llvm-gcc 4.0 and APFloat on X86_64)
On Mon, 22 Oct 2007, Dale Johannesen wrote: > In principle I think keeping IEEE float and double in an endian- > independent form in the IR files is a good idea. BUT: I'm told > retaining the ability to use files in the existing format is a > requirement (so floats still need to occupy 8 bytes). Since ARM target > doesn't currently work that one is a reasonable
2007 Oct 22
1
[LLVMdev] cross compiling for arm-softfloat-linux-gnu (was troubles with llvm-gcc 4.0 and APFloat on X86_64)
Dale Johannesen wrote: > On Oct 22, 2007, at 2:08 AM, Dietmar Ebner wrote: >> next, i think (one of) the problem(s) is the use of >> [HOST_]WORDS_BIG_ENDIAN instead of [HOST_]FLOAT_WORDS_BIG_ENDIAN in >> llvm-convert.cpp (see patch below). >> >> this fixes single precision floating point but breaks double >> precision. >> for arm-softfloat-linux-gnu,
2008 Apr 02
0
[LLVMdev] Whole-function isel
On Mar 31, 2008, at 2:37 AM, Dietmar Ebner wrote: > Evan Cheng wrote: >> That's unfortunate. What kind of licensing issues are there? > i've talked to our supporting company and they agreed to release the > code to interested parties. it's not a copyleft license but the code > can be used freely for private and research purposes. > > > be warned that the