search for: itiv

On Tue, Aug 11, 2009 at 1:13 AM, Stripf, Timo<Timo.Stripf at itiv.uni-karlsruhe.de> wrote: > On little endian machines the code works correct but on big endian %lhsv > must be compared against 73 << 8. If llvm-gcc thinks it's compiling for a little-endian target, the optimizers will assume the target is little-endian... what are you trying to...

Hi all, i'm working on a LLVM back-end right now and i think I found a bug in an optimization pass. When compiling the following code using llvm-gcc (the current 2.5 release) with -O2 int main(int argc, char** argv) { char* pStr = "I" + (argc > 100); printf("%d\n", strcmp(pStr, "I") == 0); } the strcmp

...14.210.76.12 Jun 4 14:23:48 thebighonker dovecot: auth: Debug: auth client connected (pid=0) Jun 4 14:23:48 thebighonker dovecot: auth: Debug: client in: AUTH 1 LOGIN service=smtp rip=14.210.76.12 lip=192.147.25.65 nologin resp= (previous base64 data may contain sens itive data) Jun 4 14:23:48 thebighonker dovecot: auth: Debug: auth client connected (pid=0) Jun 4 14:23:48 thebighonker dovecot: auth: Debug: client in: AUTH 1 LOGIN service=smtp rip=14.210.76.12 lip=192.147.25.65 nologin resp= (previous base64 data may contain sens itive...

Hi, i've two papers that could be listed on the LLVM publication page. http://www.llvm.org/pubs/ The first paper describes an architecture description language and LLVM back-end generation out of an ADL. The second paper describes a cluster VLIW back-end for LLVM 2.9, just before this VLIW initiative started for LLVM. Kind regards, Timo Stripf Stripf, T.; Koenig, R.; Becker, J.; , "A

I'm seeing lots of: Jun 2 00:00:05 thebighonker exim[57437]: dovecot_login authenticator failed for ec2-52-40-16-7.us-west-2.compute.amazonaws.com (ADM IN) [52.40.16.7]:51339 I=[192.147.25.65]:465: 535 Incorrect authentication data (set_id=web) Jun 2 00:00:06 thebighonker exim[57439]: dovecot_login authenticator failed for ec2-52-40-16-7.us-west-2.compute.amazonaws.com (ADM IN)

...u [mailto:llvmdev-bounces at cs.uiuc.edu] Im Auftrag von Eli Friedman Gesendet: Dienstag, 11. August 2009 10:27 An: LLVM Developers Mailing List Betreff: Re: [LLVMdev] Bug in optimization pass related to strcmp and bigendian back-ends On Tue, Aug 11, 2009 at 1:13 AM, Stripf, Timo<Timo.Stripf at itiv.uni-karlsruhe.de> wrote: > On little endian machines the code works correct but on big endian %lhsv > must be compared against 73 << 8. If llvm-gcc thinks it's compiling for a little-endian target, the optimizers will assume the target is little-endian... what are you trying to...

Hi all, i'm writing an back-end for a new research processor architecture and have problems with the DAG Combiner. The processor architecture supports i1 and i32 registers. 1-bit registers are mainly used as comparison result but basic operations like OR are not possible between i1 registers. So I wrote custom lowering for i1 OR operations and replaced it by (trunc (or (aext x), (aext

Hi Evan, I just read your proposal and the following discussion for VLIW support and want to share my experience of writing a VLIW back-end for LLVM. I would not integrate the packetizer into the register allocator super class since it would reduce the flexibility for the back-end developer to add some optimization passes after the packetizer. Instead, I would add the packetizer as a separate

Machine Instruction Bundle in LLVM Hi all, There have been quite a bit of discussions about adding machine instruction bundle to support VLIW targets. I have been pondering what the right representation should be and what kind of impact it might have on the LLVM code generator. I believe I have a fairly good plan now and would like to share with the LLVM community. Design Criteria 1. The

Hi all, i'm working atm on a backend for a processor architecture that is capable of storing the carry flag of ADDC in an 1-bit register class. So I tried to lower the ADDC instruction to generate two register values as result. On the tablegen description of the instruction i came across the tablegen restriction that only one output result of one instruction is possible:

Hi all, i'm working atm on a backend for a processor architecture that is capable of storing the carry flag of ADDC in an 1-bit register class. So I tried to lower the ADDC instruction to generate two register values as result. On the tablegen description of the instruction i came across the tablegen restriction that only one output result of one instruction is possible:

Alright thank you all for your help and information and sry for describing it as a bug. For a "fast" workaround I simple use llvm-gcc with -O0, modify the endian information within the ll file and use opt to optimize the code. That way also the debugging information is not removed and everything works atm fine for a non-trivial application. Later I'll also modify the front-end to

I converted now my back-end with legal i1 lowering to the 2.6 branch and my original problem with the DAG combiner didn't occur any more and seems to be fixed. setOperationAction(ISD::OR, MVT::i1, Promote) also works fine for logical operations. > What is your SetCCResultType now? I changed SetCCResultType to return MVT::i1 type. > Can you compile the CodeGen/Blackfin/basic-i1.ll

Hi Jakob, I forget to mention that I'm working atm on the old 2.5 release code base and not on the svn. So I don't know if the problem still exists. I'm going to test it now. > The Blackfin DSP can do simple i1 operations with the CC flag and > status bits. Initially I also marked i1 as a legal type, but it caused > a lot of problems. Now I pretend that the CC register