search for: deplinenoise

Replying to my self here. It seems I was missing an isTerminator = 1 on the branch instruction in question, so LLVM didn't know that the instruction terminated a basic block. Does that make sense, or is just masking some other problem? Thanks, Andreas On 9/28/07, Andreas Fredriksson <deplinenoise at gmail.com> wrote: > Hi, > I'm trying to write up my little m68k backend things have been going > smoothly. I've been working with the x86 backend as a template, fixing > things as I go. > > Now I've run into branches and I have a crash I don't really > und...

Hi, I'm trying to write up my little m68k backend things have been going smoothly. I've been working with the x86 backend as a template, fixing things as I go. Now I've run into branches and I have a crash I don't really understand. Here's the sample IR I'm running llc on to generate assembly: define i32 @ilog2(i32 %x) { entry: %tmp718 = icmp eq i32 %x, 0

2008/2/15, Andreas Fredriksson <deplinenoise at gmail.com>: > > I tried mocking this up using the following. (Base is what's returned as > the Ax in the move expression above when the DAG is constructed due to > SelectAddr().) > > SDOperand chain = CurDAG->getCopyToReg(Base, M68K::A3, Base); > Base = Cur...

Yeah, that will cause problems. However, I expect an assertion somewhere. Any chance you can track down the exact problem? Thanks. Evan On Sep 28, 2007, at 1:37 PM, Andreas Fredriksson <deplinenoise at gmail.com> wrote: > Replying to my self here. It seems I was missing an isTerminator = 1 > on the branch instruction in question, so LLVM didn't know that the > instruction terminated a basic block. Does that make sense, or is just > masking some other problem? > > Than...

Hi again, I'm finally getting some time to work on my m68k backend again. :) I was trying to solve the problem that loads from arbitrary addresses need to go through address registers. 68k allows flexible addressing similar to what the x86 can do, only that the adressing base has to reside in an address register: move.size[b/w/l] <Displacement>(Ax, Dx * Scale[1/2/4/8]), <Dest>

On Sep 29, 2007, at 2:57 PM, Andreas Fredriksson <deplinenoise at gmail.com> wrote: > On 9/25/07, Evan Cheng <evan.cheng at apple.com> wrote: >>> Hi Evan, >>> wouldn't this generate fairly terrible code if each address register >>> use has to be preceded by instructions to make an address register >>> hold t...

On 9/25/07, Evan Cheng <evan.cheng at apple.com> wrote: > > Hi Evan, > > wouldn't this generate fairly terrible code if each address register > > use has to be preceded by instructions to make an address register > > hold the right value? > > No. I would suggest doing this as a instruction selection post pass. > It would operate on DAGs so you still get

On Sep 24, 2007, at 1:12 AM, Andreas Fredriksson wrote: > On 9/24/07, Evan Cheng <evan.cheng at apple.com> wrote: > >> I am going to suggest something shocking. :) Since you will end up >> writing a >> bunch of target specific code anyway, you might a well write a target >> specific pass that change generic instructions into data register >> variant

On 9/23/05, Vladimir Prus <ghost at cs.msu.su> wrote: > In fact, I believe that > > using namespace llvm; > using namespace boost; > using boost::tie; > > should resove the problem witout needed to explicitly nominate all boost names > you use. Except that this does not work on global scope, but only in > namespace: <SNIP> Also, it might be an idea

On 3/12/07, Jeff Cohen <jeffc at jolt-lang.org> wrote: > Just to make clear, there are no problems building 1.9 with VS 2003, nor > are there any problems as I write this. I'm fairly sure we grabbed the 1.9 tarball off the website, but I could be wrong. > That's what we do. We define it in llvm/lib/System/Win32/Win32.h, which > in included by every file that uses the

Hi list, I'm toying with the idea of writing a m680x0 backend for LLVM, and the address modes of this chip are bewildering, to say the least. Here's a rough list off wikipedia for reference: * Register direct o data register, e.g. "D0" o address register, e.g. "A6" * Register indirect o Simple address, e.g. (A0) o

On 9/24/07, Evan Cheng <evan.cheng at apple.com> wrote: > I am going to suggest something shocking. :) Since you will end up writing a > bunch of target specific code anyway, you might a well write a target > specific pass that change generic instructions into data register variant > ones when necessary. Hi Evan, wouldn't this generate fairly terrible code if each address

I guess isUnpredicatedTerminator() and friends would just return false, but maybe there should be an assertion in an earlier pass that all instructions in the tail position of basic blocks really are terminators, or is that not required? // A On 9/29/07, Evan Cheng <evan.cheng at apple.com> wrote: > Yeah, that will cause problems. However, I expect an assertion > somewhere. Any

On 10/1/07, Evan Cheng <evan.cheng at apple.com> wrote: > > If I lower the calling convention stuff manually rather than relying > > on the generated CC analyzer, how do I determine that a formal > > argument I'm about to receive or pack together is supposed to be used > > as a pointer so I can stick it in an address register? > > I'd suggest custom

Hey guys, I just moved to the 1.5 release yesterday. I compiled the Debug version cleanly from sources (I'm not using the gcc frontend) using GCC 4.0.1 (on Fedora Core x86), and I noticed that llc hung in an STL iterator loop given trivial bytecode input (essentially a single function to add a couple of integers). The bytecode compiled fine from llvm assembly via llvm-as. The hang was in one

On 6/29/05, Chris Lattner <sabre at nondot.org> wrote: > On Mon, 27 Jun 2005, Alexander Friedman wrote: > > Hi all, > > have flex/bison. Most (but not all) unix boxes have them, but almost > > no windows boxes have them. This requires either > > > > 1) Forcing the user to dowload flex/bison (bad) > > 2) Distributing flex/bison with the front-end (not as

On 3/11/07, Reid Spencer <rspencer at reidspencer.com> wrote: > Could you submit the patch? We could make sure that 2.0 doesn't have the > same problem. Sure, I can't test this from where I am now but if anyone can take it for a spin to test it and verify the fix then by all means check it in. I'm just providing a hand-edited diff from our vendor branch here (1.9 tarball

On 3/11/07, Jeff Cohen <jeffc at jolt-lang.org> wrote: > No, the problem with StoreSDNode was that an argument as being called Value, > which hid the class Value later on in the argument list. This also broke > 2003 and was fixed a while ago. Ok, I didn't know that. We've been using the 1.9 tarball version, as I said. > _WIN32_WINNT is not supposed to be predefined,

Hi, I'm trying to describe the patterns for the m68k instructions ADD and ADDA when used with a data register operand for the source. Basically, ADD operates on anything but address registers and immediates, and ADDA works on address registers only so I'm going to need both instructions in my instruction set. These are the two problematic definitions; by themselves they produce the

On 3/10/07, Jeff Cohen <jeffc at jolt-lang.org> wrote: > It is, if only because it's the version I use, but 2005 is supposed to > work also. That being said, I wouldn't be surprised to learn that it > doesn't due to recent STL issues. Versions prior to 2003 won't work. I'm using the basic stuff (just libraries, 1.9) with 2005, although we had to fix a few