Alireza.Moshtaghi at microchip.com
2007-Oct-08 22:15 UTC
[LLVMdev] Lowering operations to 8-bit!
I am trying to verify the generated DAG after converting from llvm to DAG, however I'm not sure if this is correct or not. Here is the situation: In order to get LLVM to lower to 8-bit I have to define only 8-bit registers and the pointer size also to be 8-bit. Doing so, the attached DAG is generated for a load:i16. I have problem understanding this DAG in two places: 1)As you can see the UNDEF node is of type i8, however, we want it to be of type i16 because load is of type i16 As I trace llvm to see how it lowers, I see that it is basing the type of UNDEF on the type of its address which is i8 : SelectionDAG.cpp:2250 SDOperand Undef = getNode(ISD::UNDEF, Ptr.getValueType()) The question is why is it doing this? Shouldn't it use Ty instead of Ptr.getValueType()? 2)Ok it is using an 8-bit GlobalAddress because I told it that pointers are 8-bit, however, what if my memory is bigger? I can cascade 2 registers and address more larger memory than only a 256-byte long. The question is how can I make it generate GlobalAddress:i16 and later break it down to two 8-bit values? Thanks. A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Wednesday, October 03, 2007 11:22 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Lowering operations to 8-bit! On Oct 3, 2007, at 3:21 PM, Alireza.Moshtaghi at microchip.com wrote:> Thank you Evan, > I added the return Type::Int8Ty to the switch statement to get it to > work. > I don't know if this can have other consequences, I haven't yet > verified > if the generated Legalized DAG is correct though.If this works, please submit a patch. Otherwise please submit a bug report with as much information as possible. Thanks, Evan> > A. > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Evan Cheng > Sent: Monday, October 01, 2007 3:23 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Lowering operations to 8-bit! > > > On Oct 1, 2007, at 11:33 AM, Alireza.Moshtaghi at microchip.com wrote: > >> So does that mean that LLVM can't lower automatically to 8-bit >> values? > > There is no inherent reason. LLVM should be able to lower to 8-bit > values. It's probably a bug somewhere. > > In TargetLowering.h: > > bool isTypeLegal(MVT::ValueType VT) const { > return !MVT::isExtendedVT(VT) && RegClassForVT[VT] != 0; > } > > Is there a 16-bit register class? > >> I tried defining 8-bit pointers in the subtarget using "p:8:8:8" >> but it >> asserts at line 566 of TargetData.cpp in the default case of >> TargetData::getIntPtrType() > > Dunno why it's like this. Can you add case 1: return Type::Int8Ty? > Does it work / help? > > Evan > >> >> Is it difficult to add 8-bit support? >> >> A. >> >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- >> bounces at cs.uiuc.edu] >> On Behalf Of Chris Lattner >> Sent: Friday, September 28, 2007 5:01 PM >> To: LLVM Developers Mailing List >> Subject: Re: [LLVMdev] Lowering operations to 8-bit! >> >> >> On Sep 28, 2007, at 4:53 PM, <Alireza.Moshtaghi at microchip.com> >> <Alireza.Moshtaghi at microchip.com> wrote: >> >>> ExpandOp is not called at all. >>> In SelectionDAGLegalize::HandleOp() only the ValueType is >>> considered in >>> the switch statement to decide if it is legal or promote or expand. >>> As I trace back (correct me if I'm wrong) these values are set in >>> TargetLowering::computeRegisterProperties() and it is based on the >>> largest register class (in my case the smallest possible pointer >>> size, >>> 16-bit) >>> So it reduces everything down to 16-bit and pretty much ignores the >>> fact >>> that ADD of i16 is supposed to be expanded. >>> >>> Am I doing the right analysis? >> >> Yes. It sounds like the codegen is assuming the pointer type is >> valid in computeRegisterProperties or something. Somehow i16 is >> getting marked as legal. >> >> -Chris >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev_______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- A non-text attachment was scrubbed... Name: graph.ps Type: application/postscript Size: 14855 bytes Desc: graph.ps URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071008/21478a80/attachment.ps>
Alireza.Moshtaghi at microchip.com
2007-Oct-09 16:26 UTC
[LLVMdev] Lowering operations to 8-bit!
When I change SelectionDAG.cpp:2250 from: SDOperand Undef = getNode(ISD::UNDEF, Ptr.getValueType()) to: SDOperand Undef = getNode(ISD::UNDEF, VT) It behaves as I expect it generates a node of UNDEF:i16 then lowers it to two 8-bits and the DAG seems to be correct now. Please let me know if this is a bug in LLVM or I am doing something wrong. Thanks. Ali -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Alireza.Moshtaghi at microchip.com Sent: Monday, October 08, 2007 3:16 PM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Lowering operations to 8-bit! I am trying to verify the generated DAG after converting from llvm to DAG, however I'm not sure if this is correct or not. Here is the situation: In order to get LLVM to lower to 8-bit I have to define only 8-bit registers and the pointer size also to be 8-bit. Doing so, the attached DAG is generated for a load:i16. I have problem understanding this DAG in two places: 1)As you can see the UNDEF node is of type i8, however, we want it to be of type i16 because load is of type i16 As I trace llvm to see how it lowers, I see that it is basing the type of UNDEF on the type of its address which is i8 : SelectionDAG.cpp:2250 SDOperand Undef = getNode(ISD::UNDEF, Ptr.getValueType()) The question is why is it doing this? Shouldn't it use Ty instead of Ptr.getValueType()? 2)Ok it is using an 8-bit GlobalAddress because I told it that pointers are 8-bit, however, what if my memory is bigger? I can cascade 2 registers and address more larger memory than only a 256-byte long. The question is how can I make it generate GlobalAddress:i16 and later break it down to two 8-bit values? Thanks. A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Wednesday, October 03, 2007 11:22 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Lowering operations to 8-bit! On Oct 3, 2007, at 3:21 PM, Alireza.Moshtaghi at microchip.com wrote:> Thank you Evan, > I added the return Type::Int8Ty to the switch statement to get it to > work. > I don't know if this can have other consequences, I haven't yet > verified > if the generated Legalized DAG is correct though.If this works, please submit a patch. Otherwise please submit a bug report with as much information as possible. Thanks, Evan> > A. > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Evan Cheng > Sent: Monday, October 01, 2007 3:23 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Lowering operations to 8-bit! > > > On Oct 1, 2007, at 11:33 AM, Alireza.Moshtaghi at microchip.com wrote: > >> So does that mean that LLVM can't lower automatically to 8-bit >> values? > > There is no inherent reason. LLVM should be able to lower to 8-bit > values. It's probably a bug somewhere. > > In TargetLowering.h: > > bool isTypeLegal(MVT::ValueType VT) const { > return !MVT::isExtendedVT(VT) && RegClassForVT[VT] != 0; > } > > Is there a 16-bit register class? > >> I tried defining 8-bit pointers in the subtarget using "p:8:8:8" >> but it >> asserts at line 566 of TargetData.cpp in the default case of >> TargetData::getIntPtrType() > > Dunno why it's like this. Can you add case 1: return Type::Int8Ty? > Does it work / help? > > Evan > >> >> Is it difficult to add 8-bit support? >> >> A. >> >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- >> bounces at cs.uiuc.edu] >> On Behalf Of Chris Lattner >> Sent: Friday, September 28, 2007 5:01 PM >> To: LLVM Developers Mailing List >> Subject: Re: [LLVMdev] Lowering operations to 8-bit! >> >> >> On Sep 28, 2007, at 4:53 PM, <Alireza.Moshtaghi at microchip.com> >> <Alireza.Moshtaghi at microchip.com> wrote: >> >>> ExpandOp is not called at all. >>> In SelectionDAGLegalize::HandleOp() only the ValueType is >>> considered in >>> the switch statement to decide if it is legal or promote or expand. >>> As I trace back (correct me if I'm wrong) these values are set in >>> TargetLowering::computeRegisterProperties() and it is based on the >>> largest register class (in my case the smallest possible pointer >>> size, >>> 16-bit) >>> So it reduces everything down to 16-bit and pretty much ignores the >>> fact >>> that ADD of i16 is supposed to be expanded. >>> >>> Am I doing the right analysis? >> >> Yes. It sounds like the codegen is assuming the pointer type is >> valid in computeRegisterProperties or something. Somehow i16 is >> getting marked as legal. >> >> -Chris >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev_______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Oct 8, 2007, at 3:15 PM, Alireza.Moshtaghi at microchip.com wrote:> I am trying to verify the generated DAG after converting from llvm to > DAG, however I'm not sure if this is correct or not. > Here is the situation: > In order to get LLVM to lower to 8-bit I have to define only 8-bit > registers and the pointer size also to be 8-bit. > Doing so, the attached DAG is generated for a load:i16. > > > I have problem understanding this DAG in two places: > > 1)As you can see the UNDEF node is of type i8, however, we want it > to be > of type i16 because load is of type i16 > As I trace llvm to see how it lowers, I see that it is basing the type > of UNDEF on the type of its address which is i8 : > SelectionDAG.cpp:2250 > SDOperand Undef = getNode(ISD::UNDEF, Ptr.getValueType()) > The question is why is it doing this? Shouldn't it use Ty instead of > Ptr.getValueType()? > > 2)Ok it is using an 8-bit GlobalAddress because I told it that > pointers > are 8-bit, however, what if my memory is bigger? I can cascade 2 > registers and address more larger memory than only a 256-byte long. > The question is how can I make it generate GlobalAddress:i16 and later > break it down to two 8-bit values?Hrm. Looks like there is some confusion. What is the size of the addressable space? Setting ptr type to 8-bit means the size of the address is at most 256-byte. That seems awfully small. :-) Is this a 16-bit machine you are targeting? If so, please try setting pointer type to i16. Evan> > > Thanks. > A. > > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Evan Cheng > Sent: Wednesday, October 03, 2007 11:22 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Lowering operations to 8-bit! > > > On Oct 3, 2007, at 3:21 PM, Alireza.Moshtaghi at microchip.com wrote: > >> Thank you Evan, >> I added the return Type::Int8Ty to the switch statement to get it to >> work. >> I don't know if this can have other consequences, I haven't yet >> verified >> if the generated Legalized DAG is correct though. > > If this works, please submit a patch. Otherwise please submit a bug > report with as much information as possible. > > Thanks, > > Evan > >> >> A. >> >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- >> bounces at cs.uiuc.edu] >> On Behalf Of Evan Cheng >> Sent: Monday, October 01, 2007 3:23 PM >> To: LLVM Developers Mailing List >> Subject: Re: [LLVMdev] Lowering operations to 8-bit! >> >> >> On Oct 1, 2007, at 11:33 AM, Alireza.Moshtaghi at microchip.com wrote: >> >>> So does that mean that LLVM can't lower automatically to 8-bit >>> values? >> >> There is no inherent reason. LLVM should be able to lower to 8-bit >> values. It's probably a bug somewhere. >> >> In TargetLowering.h: >> >> bool isTypeLegal(MVT::ValueType VT) const { >> return !MVT::isExtendedVT(VT) && RegClassForVT[VT] != 0; >> } >> >> Is there a 16-bit register class? >> >>> I tried defining 8-bit pointers in the subtarget using "p:8:8:8" >>> but it >>> asserts at line 566 of TargetData.cpp in the default case of >>> TargetData::getIntPtrType() >> >> Dunno why it's like this. Can you add case 1: return Type::Int8Ty? >> Does it work / help? >> >> Evan >> >>> >>> Is it difficult to add 8-bit support? >>> >>> A. >>> >>> -----Original Message----- >>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- >>> bounces at cs.uiuc.edu] >>> On Behalf Of Chris Lattner >>> Sent: Friday, September 28, 2007 5:01 PM >>> To: LLVM Developers Mailing List >>> Subject: Re: [LLVMdev] Lowering operations to 8-bit! >>> >>> >>> On Sep 28, 2007, at 4:53 PM, <Alireza.Moshtaghi at microchip.com> >>> <Alireza.Moshtaghi at microchip.com> wrote: >>> >>>> ExpandOp is not called at all. >>>> In SelectionDAGLegalize::HandleOp() only the ValueType is >>>> considered in >>>> the switch statement to decide if it is legal or promote or expand. >>>> As I trace back (correct me if I'm wrong) these values are set in >>>> TargetLowering::computeRegisterProperties() and it is based on the >>>> largest register class (in my case the smallest possible pointer >>>> size, >>>> 16-bit) >>>> So it reduces everything down to 16-bit and pretty much ignores the >>>> fact >>>> that ADD of i16 is supposed to be expanded. >>>> >>>> Am I doing the right analysis? >>> >>> Yes. It sounds like the codegen is assuming the pointer type is >>> valid in computeRegisterProperties or something. Somehow i16 is >>> getting marked as legal. >>> >>> -Chris >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > <graph.ps>_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Alireza.Moshtaghi at microchip.com
2007-Oct-09 20:57 UTC
[LLVMdev] Lowering operations to 8-bit!
Evan, The machine is 8 bit, and of course all registers are 8-bit too. Memory access on this machine is a bit different. The memory is banked into banks of 256-byte, and you can select the active bank using a bank select register. All instructions can access the memory with an 8-bit operand, so in that sense the address space can be viewed as 256-byte long. On the other hand, there are three shadowed locations of each bank that two of them act as index registers, and if you access (read/write) to the third register, the memory at address pointed to by the first two registers will be accessed (no banking in this mode) At first I created a class of 16-bit registers for the two special registers, but since LLVM only lowers to the largest register class size (16-bit), it did not lower the rest of the operations to 8-bit. So I had to get rid of the 16-bit register class and now LLVM lowers to 8-bit operations, but I have ended up with pointer size of 8-bit. Still I think there are tricks that I may be able to play by customizing the GlobalAddress DAG and preloading the index registers. However, first I would like to solicit your input and make sure that this is really what I want to do. Regards Ali. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Tuesday, October 09, 2007 1:24 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Lowering operations to 8-bit! On Oct 8, 2007, at 3:15 PM, Alireza.Moshtaghi at microchip.com wrote:> I am trying to verify the generated DAG after converting from llvm to > DAG, however I'm not sure if this is correct or not. > Here is the situation: > In order to get LLVM to lower to 8-bit I have to define only 8-bit > registers and the pointer size also to be 8-bit. > Doing so, the attached DAG is generated for a load:i16. > > > I have problem understanding this DAG in two places: > > 1)As you can see the UNDEF node is of type i8, however, we want it > to be > of type i16 because load is of type i16 > As I trace llvm to see how it lowers, I see that it is basing the type > of UNDEF on the type of its address which is i8 : > SelectionDAG.cpp:2250 > SDOperand Undef = getNode(ISD::UNDEF, Ptr.getValueType()) > The question is why is it doing this? Shouldn't it use Ty instead of > Ptr.getValueType()? > > 2)Ok it is using an 8-bit GlobalAddress because I told it that > pointers > are 8-bit, however, what if my memory is bigger? I can cascade 2 > registers and address more larger memory than only a 256-byte long. > The question is how can I make it generate GlobalAddress:i16 and later > break it down to two 8-bit values?Hrm. Looks like there is some confusion. What is the size of the addressable space? Setting ptr type to 8-bit means the size of the address is at most 256-byte. That seems awfully small. :-) Is this a 16-bit machine you are targeting? If so, please try setting pointer type to i16. Evan> > > Thanks. > A. > > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Evan Cheng > Sent: Wednesday, October 03, 2007 11:22 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Lowering operations to 8-bit! > > > On Oct 3, 2007, at 3:21 PM, Alireza.Moshtaghi at microchip.com wrote: > >> Thank you Evan, >> I added the return Type::Int8Ty to the switch statement to get it to >> work. >> I don't know if this can have other consequences, I haven't yet >> verified >> if the generated Legalized DAG is correct though. > > If this works, please submit a patch. Otherwise please submit a bug > report with as much information as possible. > > Thanks, > > Evan > >> >> A. >> >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- >> bounces at cs.uiuc.edu] >> On Behalf Of Evan Cheng >> Sent: Monday, October 01, 2007 3:23 PM >> To: LLVM Developers Mailing List >> Subject: Re: [LLVMdev] Lowering operations to 8-bit! >> >> >> On Oct 1, 2007, at 11:33 AM, Alireza.Moshtaghi at microchip.com wrote: >> >>> So does that mean that LLVM can't lower automatically to 8-bit >>> values? >> >> There is no inherent reason. LLVM should be able to lower to 8-bit >> values. It's probably a bug somewhere. >> >> In TargetLowering.h: >> >> bool isTypeLegal(MVT::ValueType VT) const { >> return !MVT::isExtendedVT(VT) && RegClassForVT[VT] != 0; >> } >> >> Is there a 16-bit register class? >> >>> I tried defining 8-bit pointers in the subtarget using "p:8:8:8" >>> but it >>> asserts at line 566 of TargetData.cpp in the default case of >>> TargetData::getIntPtrType() >> >> Dunno why it's like this. Can you add case 1: return Type::Int8Ty? >> Does it work / help? >> >> Evan >> >>> >>> Is it difficult to add 8-bit support? >>> >>> A. >>> >>> -----Original Message----- >>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- >>> bounces at cs.uiuc.edu] >>> On Behalf Of Chris Lattner >>> Sent: Friday, September 28, 2007 5:01 PM >>> To: LLVM Developers Mailing List >>> Subject: Re: [LLVMdev] Lowering operations to 8-bit! >>> >>> >>> On Sep 28, 2007, at 4:53 PM, <Alireza.Moshtaghi at microchip.com> >>> <Alireza.Moshtaghi at microchip.com> wrote: >>> >>>> ExpandOp is not called at all. >>>> In SelectionDAGLegalize::HandleOp() only the ValueType is >>>> considered in >>>> the switch statement to decide if it is legal or promote or expand. >>>> As I trace back (correct me if I'm wrong) these values are set in >>>> TargetLowering::computeRegisterProperties() and it is based on the >>>> largest register class (in my case the smallest possible pointer >>>> size, >>>> 16-bit) >>>> So it reduces everything down to 16-bit and pretty much ignores the >>>> fact >>>> that ADD of i16 is supposed to be expanded. >>>> >>>> Am I doing the right analysis? >>> >>> Yes. It sounds like the codegen is assuming the pointer type is >>> valid in computeRegisterProperties or something. Somehow i16 is >>> getting marked as legal. >>> >>> -Chris >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > <graph.ps>_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev_______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev