search for: bits1

In matcher/expandweight.cc we have: OmExpandBits operator+(const OmExpandBits &bits1, const OmExpandBits &bits2) { OmExpandBits sum(bits1); sum.multiplier += bits2.multiplier; sum.rtermfreq += bits2.rtermfreq; // FIXME - try to share this information rather than pick half of it if (bits2.dbsize > sum.dbsize) { DEBUGLINE(WTCALC, "OmExpan...

...u *Subject:* [LLVMdev] DFAPacketizer Hi, I am having problems writing the ProcessorItineraries list. As instructions on my VLIW target have varying size I want to model both cpu units and bundle bits as FUs. The following does not work, to my surprise: InstrItinData<ALU, [InstrStage<1, [BITS1,BITS2, BITS3, BITS4], 0>, InstrStage<1, [ALU1, ALU2]>]> I want to express that there are two ALU's, and four bundle slots, and in this case while allocating this type of instructions several times, I would like to be allowed only two such instructions per cycle. ResourceTracker...

...gt; Hi, > > I am having problems writing the ProcessorItineraries list. As > instructions on my VLIW target have varying size I want to model both > cpu units and bundle bits as FUs. The following does not work, to my > surprise: > > InstrItinData<ALU, [InstrStage<1, [BITS1,BITS2, BITS3, BITS4], 0>, > > InstrStage<1, [ALU1, ALU2]>]> > > I want to express that there are two ALU's, and four bundle slots, and > in this case while allocating this type of instructions several times, > I would like to be allowed only two such instructions...

...u> Subject: [LLVMdev] DFAPacketizer Hi, I am having problems writing the ProcessorItineraries list. As instructions on my VLIW target have varying size I want to model both cpu units and bundle bits as FUs. The following does not work, to my surprise: InstrItinData<ALU, [InstrStage<1, [BITS1,BITS2, BITS3, BITS4], 0>, InstrStage<1, [ALU1, ALU2]>]> I want to express that there are two ALU's, and four bundle slots, and in this case while allocating this type of instructions several times, I would like to be allowed only two such instructions...

...u> Subject: [LLVMdev] DFAPacketizer Hi, I am having problems writing the ProcessorItineraries list. As instructions on my VLIW target have varying size I want to model both cpu units and bundle bits as FUs. The following does not work, to my surprise: InstrItinData<ALU, [InstrStage<1, [BITS1,BITS2, BITS3, BITS4], 0>, InstrStage<1, [ALU1, ALU2]>]> I want to express that there are two ALU's, and four bundle slots, and in this case while allocating this type of instructions several times, I would like to be allowed only two such instructions...

Hi, I am having problems writing the ProcessorItineraries list. As instructions on my VLIW target have varying size I want to model both cpu units and bundle bits as FUs. The following does not work, to my surprise: InstrItinData<ALU, [InstrStage<1, [BITS1,BITS2, BITS3, BITS4], 0>, InstrStage<1, [ALU1, ALU2]>]> I want to express that there are two ALU's, and four bundle slots, and in this case while allocating this type of instructions several times, I would like to be allowed only two such instructions...

...along. Instead of writing assembly for each machine, we should be >> using LLVM assembly code and writing part of the bignum library on the >> "other side" of this interface. >> >> If you have time, check out the cminusminus language reference. They >> had a bits1 type for flags, like carry from addition, and a mulhi and >> mullo instruction. Now cminusminus never took off and died an untimely >> death (largely because they wrote it in some bizarre ML in my >> opinion), but from a bignum point of view, they got this one minor >> detai...

...this wrong all > along. Instead of writing assembly for each machine, we should be > using LLVM assembly code and writing part of the bignum library on the > "other side" of this interface. > > If you have time, check out the cminusminus language reference. They > had a bits1 type for flags, like carry from addition, and a mulhi and > mullo instruction. Now cminusminus never took off and died an untimely > death (largely because they wrote it in some bizarre ML in my > opinion), but from a bignum point of view, they got this one minor > detail right. Hmm......

Hi all, After searching for a decent compiler backend for ages (google sometimes isn't helpful), I recently stumbled upon LLVM. Woot!! I work on bignum arithmetic (I'm a professional mathematician) and have recently decided to switch from developing GPL'd bignum code to BSD licensed code. (See http://www.mpir.org/ which I contributed to for a while - a fork of GMP). Please bear with