search for: kendyck

Hi, One of the long-standing code clean-up bugs in Bugzilla is to extract the Machine* code from the CodeGen library into a separate one, on which CodeGen depends ( http://llvm.org/bugs/show_bug.cgi?id=1121). I'd like to start working on this. The general approach I'm planning to take is: 1. Identify which code to move. 2. Eliminate all dependencies that the Machine code has on the

On Tue, Mar 1, 2011 at 4:06 PM, David Neto wrote: > On Mon, Feb 28, 2011 at 4:41 PM, Peter Collingbourne wrote: >> >> The more I think about it, the more I become uncomfortable with the >> concept of language-specific address spaces in LLVM.  These are the >> main issues I see with language-specific address spaces: > > ... > >> Instead of language-specific

On Sep 5, 2013, at 5:15 PM, Ken Dyck <kd at kendyck.com> wrote: > Hi, > > One of the long-standing code clean-up bugs in Bugzilla is to extract > the Machine* code from the CodeGen library into a separate one, on > which CodeGen depends ( > http://llvm.org/bugs/show_bug.cgi?id=1121). > > I'd like to start working on...

In SelectionDAGBuilder::visitRet(), there is this bit of code: // FIXME: C calling convention requires the return type to be promoted // to at least 32-bit. But this is not necessary for non-C calling // conventions. The frontend should mark functions whose return values // require promoting with signext or zeroext attributes. if (ExtendKind !=

Two functions in DwarfDebug, addBlockByrefAddress() and addComplexAddress(), contain this snippet of code: // Decode the original location, and use that as the start of the byref // variable's location. const TargetRegisterInfo *RI = Asm->TM.getRegisterInfo(); unsigned Reg = RI->getDwarfRegNum(Location.getReg(), false); DIEBlock *Block = new (DIEValueAllocator) DIEBlock();

On Wed, Mar 16, 2011 at 12:35 PM, Cameron Zwarich <zwarich at apple.com> wrote: > On Mar 16, 2011, at 9:31 AM, Cameron Zwarich wrote: > >> Promoting the return value is unsafe for bool returns on x86-64, which >> in the latest revision of the ABI only guarantees that the top 7 bits of >> the 8-bit register are 0. > > My comment is a bit off, because the question

DwarfDebug::emitDebugInfo() always appends four zero bytes to the tail of the debug info section: emitDIE(Die); // FIXME - extra padding for gdb bug. Asm->OutStreamer.AddComment("4 extra padding bytes for GDB"); Asm->EmitInt8(0); Asm->EmitInt8(0); Asm->EmitInt8(0); Asm->EmitInt8(0);

On Fri, Jan 28, 2011 at 6:29 AM, David Given <dg at cowlark.com> wrote: > For a hypothetical Evil Project(tm), I would like to do a LLVM backend > for a virtual machine that does not use 8-bit bytes. Does LLVM support > this sort of thing? Not without some modification. I've developed an LLVM back end for a DSP with 24-bit word-addressable memory, basically by defining the

On Wed, Sep 11, 2013 at 12:29 AM, Andrew Trick <atrick at apple.com> wrote: > > If that is the goal, then you only want the modules for Machine IR, and maybe some core analysis passes. The “Machine” modules you listed above include machine code analysis or transform passes that you probably don’t want. Pruning the list to basic IR support: > >> - MachineBasicBlock >> -

On Tue, Mar 8, 2011 at 5:14 AM, Jacques Van Damme <Jacques.VanDamme at synopsys.com> wrote: > I am writing a backend for an architecture that has only 16-bit word > addressing (No byte addresses ever.  All data are always 16-bit). > > How can I specify this in the backend? In short, you can't. Word-addressable memory is not currently supported in LLVM (or Clang, for that

On Thu, Feb 24, 2011 at 1:14 PM, Anton Lokhmotov <Anton.Lokhmotov at arm.com> wrote: > Hi Peter, > > Many thanks for your prompt review. > >> I don't think we should include the word OpenCL in the name of this >> enum/header.  We may very well in the future want to define address >> space constants for other languages, which should not overlap with >>