From jyasskin at google.com Sun Nov 1 01:40:50 2009 From: jyasskin at google.com (Jeffrey Yasskin) Date: Sat, 31 Oct 2009 23:40:50 -0700 Subject: [LLVMdev] Should LLVM JIT default to lazy or non-lazy? In-Reply-To: <4AEAAECE.3040102@gmail.com> References:

<0A272AD2-24B8-4FF6-8F0C-3A291CE5DBBE@apple.com> <4AEA0971.6020803@lip6.fr> <4AEAAECE.3040102@gmail.com> Message-ID: 2009/10/30 T?r?k Edwin : > On 2009-10-29 23:55, Jeffrey Yasskin wrote: >> On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray >> wrote: >> >>> Hi Jeffrey, >>> >>> Jeffrey Yasskin wrote: >>> >>>> Cool, I'll start implementing it. >>>> >>>> >>> Great! Thanks. >>> >>> Just to clarify things: on my end, it doesn't really matter what is the >>> default behavior, as long as vmkit can continue to have the existing >>> behavior of lazy compilation. With Chris' solution, I was wondering how you >>> would implement the getPointerToFunction{Eager, Lazy} functions when the >>> getPointerToFunction is called by the JIT, not the user. For example, when >>> Function F calls Function G and the JIT needs an address for G (either a >>> callback or the function address), how will it know if it must call >>> getPointerToFunctionEager or getPointerToFunctionLazy? Do you plan on >>> continuing having a flag that enables/disables lazy compilation and poll >>> this flag on each function call? How is that different than the existing >>> system? >>> >> >> Semantically, I'll thread the flag through all the calls that may >> eventually need to recursively call getPointerToFunction. To implement >> that without having to modify lots of calls, I'll probably replace the >> current public default eager/lazy setting with a private flag with >> values {Unknown, Lazy, Eager}, set it on entry and exit of >> getPointerToFunction, and check it on each internal recursive call. >> The difference with the current system is that the user is forced to >> set the flag to their desired value whenever they call into the JIT, >> rather than relying on a default. That choice then propagates through >> the whole recursive tree of codegens, without affecting the next tree. >> >> Note that I'm using getPointerToFunction as an abbreviation for the >> 3ish public functions that'll need to take this option. > > The documentation should also be updated > (http://llvm.org/docs/ProgrammersManual.html#threading) to reflect what > one needs to do, > to ensure thread-safe JITing. Thanks for that reminder. I've updated it in the patch I'm about to mail, but I should apply the update regardless of whether the rest of the patch goes in. > Also does every JIT target support non-lazy JITing now? ?See PR4816, > last time I checked (r83242) it only worked on X86, and failed on PPC; > so I had to keep lazy JITing enabled even if its not what I want for > many reasons. It's still the case that only X86 supports eager jitting. It doesn't look that hard to add it to the rest of the targets though. > Also perhaps the lazy compilation stub should spin waiting on a lock > (implemented using atomics), and the compilation callback should > execute while holding the lock just before patching the callsite, so it > would look like this in pseudocode: Good idea. This increases the code size a bit, but it's clearly better than the "load the target address" option I mentioned in the bug. Would you add it to the bug so we don't lose it? I think we can put the entire "not yet patched" branch inside the compilation callback to minimize the code size impact: callsite_patch_state = 0;// for each callsite one byte of memory callsite: if (atomic_load(&callsite_patch_state) != 2) { call CompilationCallback // Doesn't return until the patchsite is patched. } //fast- and slow-path: already compiled and patched patchsite: call // will be patched > callsite_patch_state = 0;// for each callsite one byte of memory > > callsite: > if ?(atomic_load(&callsite_patch_state) == 2) { > ? ? ?//fast-path: already compiled and patched > patchsite: > ? ? ? jmp // will be patched > } > // not yet patched, it may already be compiling > if ?(atomic_test_and_set(&callsite_patch_state, 0, 1) == 0) { > ? ? ?// not yet compiling, set state to compiling, and start compiling > ? ? ?call CompilationCallBack > ? ? ?// set state to patched > ? ? ?atomic_set(&callsite_patch_state, 2) > } > // wait for patched state > while (atomic_load(&callsite_patch_state) != 2) { > ?waitJIT(); > } > // serialize > CPUID > patchsite2: > // execute new code > jmp // will be patched > > waitJIT: > ? ?jitLock() > ? ?jitUnlock() > > ^This should be consistent with the Intel Manual's requirements on XMC, > which has a similar algorithm, except for the fast-path. > > CompilationCallBack: > ? jitLock(); > ? ? ? ?if (isJITed(F)) {jitUnlock(); return;} > ? ? ? ?JIT function > > ? ? ? ?patch_callsite(&patchsite, compiledFunctionAddress); > ? ? ? ?patch_callsite(&patchsite2, compiledFunctionAddress); > ? ? ? ?setJITed(F, true); > > ? jitUnlock(); > > This way once it is compiled the callsite will only execute: > ? ?atomic_load(&callsite_patch_state) > ? ?== 2 > ? ?jmp compiledFunctionAddress > > Best regards, > --Edwin > From mdevan.foobar at gmail.com Sun Nov 1 01:47:59 2009 From: mdevan.foobar at gmail.com (Mahadevan R) Date: Sun, 1 Nov 2009 12:17:59 +0530 Subject: [LLVMdev] Something wrong with my libpthread.so In-Reply-To: References: Message-ID: Hi, On Sat, Oct 31, 2009 at 11:42 AM, Nan Zhu wrote: > Hi,all > > I tried to run the generated whole-program bitcode of BIND,but I got some > information: > > 0?? lli???????????? 0x0000000000feda16 > 1?? lli???????????? 0x0000000000fed88f > 2?? libpthread.so.0 0x0000003df340eee0 > 3?? libc.so.6?????? 0x0000003df28332f5 gsignal + 53 > 4?? libc.so.6?????? 0x0000003df2834b20 abort + 384 > 5?? libc.so.6?????? 0x0000003df282c2fa __assert_fail + 234 > 6?? lli???????????? 0x000000000085ece9 > llvm::SmallVectorImpl::operator[](unsigned int) + 77 > 7?? lli???????????? 0x0000000000850ce0 > llvm::BitcodeReader::ParseMetadataAttachment() + 448 > 8?? lli???????????? 0x0000000000851043 Looks like a bug in the following piece of code, from BitcodeReader::ParseMetadataAttachment(): 1601 case bitc::METADATA_ATTACHMENT: { 1602 unsigned RecordLength = Record.size(); 1603 if (Record.empty() || (RecordLength - 1) % 2 == 1) 1604 return Error ("Invalid METADATA_ATTACHMENT reader!"); 1605 Instruction *Inst = InstructionList[Record[0]]; 1606 for (unsigned i = 1; i != RecordLength; i = i+2) { 1607 unsigned Kind = Record[i]; 1608 Value *Node = MDValueList.getValueFwdRef(Record[i+1]); 1609 TheMetadata.addMD(Kind, cast(Node), Inst); 1610 } 1611 break; 1612 } At line 1606, i never becomes equal to RecordLength. Regards, -Mahadevan. From nicholas at mxc.ca Sun Nov 1 01:51:22 2009 From: nicholas at mxc.ca (Nick Lewycky) Date: Sat, 31 Oct 2009 23:51:22 -0700 Subject: [LLVMdev] Something wrong with my libpthread.so In-Reply-To: References: Message-ID: <4AED2FEA.8030205@mxc.ca> Mahadevan R wrote: > Hi, > > On Sat, Oct 31, 2009 at 11:42 AM, Nan Zhu wrote: >> Hi,all >> >> I tried to run the generated whole-program bitcode of BIND,but I got some >> information: >> >> 0 lli 0x0000000000feda16 >> 1 lli 0x0000000000fed88f >> 2 libpthread.so.0 0x0000003df340eee0 >> 3 libc.so.6 0x0000003df28332f5 gsignal + 53 >> 4 libc.so.6 0x0000003df2834b20 abort + 384 >> 5 libc.so.6 0x0000003df282c2fa __assert_fail + 234 >> 6 lli 0x000000000085ece9 >> llvm::SmallVectorImpl::operator[](unsigned int) + 77 >> 7 lli 0x0000000000850ce0 >> llvm::BitcodeReader::ParseMetadataAttachment() + 448 >> 8 lli 0x0000000000851043 > > Looks like a bug in the following piece of code, from > BitcodeReader::ParseMetadataAttachment(): > > 1601 case bitc::METADATA_ATTACHMENT: { > 1602 unsigned RecordLength = Record.size(); > 1603 if (Record.empty() || (RecordLength - 1) % 2 == 1) > 1604 return Error ("Invalid METADATA_ATTACHMENT reader!"); > 1605 Instruction *Inst = InstructionList[Record[0]]; > 1606 for (unsigned i = 1; i != RecordLength; i = i+2) { > 1607 unsigned Kind = Record[i]; > 1608 Value *Node = MDValueList.getValueFwdRef(Record[i+1]); > 1609 TheMetadata.addMD(Kind, cast(Node), Inst); > 1610 } > 1611 break; > 1612 } > > At line 1606, i never becomes equal to RecordLength. I strongly suspect this is llvm.org/PR5278 . Please add your comments there, thanks! Nick From jyasskin at google.com Sun Nov 1 01:09:14 2009 From: jyasskin at google.com (Jeffrey Yasskin) Date: Sun, 1 Nov 2009 00:09:14 -0700 Subject: [LLVMdev] Should LLVM JIT default to lazy or non-lazy? In-Reply-To: References: <74c447500910281007t527c2e3cvbd6ff1335f290056@mail.gmail.com>

<0A272AD2-24B8-4FF6-8F0C-3A291CE5DBBE@apple.com> Message-ID: A possible patch implementing this is at http://codereview.appspot.com/144074 (http://codereview.appspot.com/download/issue144074_1.diff). I do NOT think we should accept this patch: It changes a lot of APIs and makes users specify the choice in many places, while I think most users really just want one choice for their whole app. There's a good argument to be made that users may want to decide certain calls should be lazily-compiled, but those are boundaries _within_ a transitive call tree, not the whole-tree choice this change allows. I'd be happy with a forced choice when creating the JIT, or with an optional choice defaulted to the safer option, but this patch seems like the wrong thing to do. Evan, you wrote, "there are existing customers out there that are using previous llvm release who will not appreciate the API change." Who are they? Recall that after my original change they can get back to lazy compilation by adding jit->DisableLazyCompilation(false) to their code. They have no need for #ifdefs. I still think that having a default that's right in nearly all cases is the best option (the only concrete counter-example I've seen is lli), but I'm happy to write another patch with a global forced choice or commit this one if that's what you guys want. On Thu, Oct 29, 2009 at 11:46 AM, Jeffrey Yasskin wrote: > Cool, I'll start implementing it. > > Thanks all for the decision! > > On Thu, Oct 29, 2009 at 11:03 AM, Evan Cheng wrote: >> I have no objection to Chris' proposal. >> >> Evan >> >> On Oct 29, 2009, at 9:45 AM, Jeffrey Yasskin wrote: >> >>> Are you objecting to Chris's proposal? I was waiting to implement it >>> until you replied so I wouldn't have to implement two things. I >>> disagree with a lot of what you wrote below, but it's not worth >>> arguing about if there's a compromise we can both live with. >>> >>> On Thu, Oct 29, 2009 at 12:36 AM, Evan Cheng wrote: >>>> There is nothing here that prevents users from enabling or disabling lazy >>>> JIT. We're talk about flipping the default behavior. That does not make the >>>> API any better or worse. Nor does it fix the inherent thread safety issue. >>>> >>>> I can tell you there are no Apple clients that depend on the lazy JIT. >>>> Please do not imply I am being secretive. I am simply busy. My objection is >>>> simple. Changing API simply for the sake of flipping default behavior does >>>> not seem like a good trade off to me. You may not feel the pain, but there >>>> are existing customers out there that are using previous llvm release who >>>> will not appreciate the API change. >>>> >>>> To me, the decision is simple. People who have done the work in the past >>>> have made their choices. We better respect their choices unless we are >>>> replacing them with something better. Flipping the default isn't better. If >>>> someone wants to sign up to design a new API, that person(s) get to decide >>>> on the default behavior. It's simple as that. >>>> >>>> For behavior / API change like this, we better extend llvm-config (or some >>>> other means) to expose that information. So the existing clients can at >>>> least ifdef the code. >>>> >>>> Evan >>>> >>>> On Oct 28, 2009, at 1:31 PM, Jeffrey Yasskin wrote: >>>> >>>>> On Wed, Oct 28, 2009 at 12:21 PM, Evan Cheng wrote: >>>>>> >>>>>> On Oct 28, 2009, at 10:07 AM, Chandler Carruth wrote: >>>>>> >>>>>>> From where I sit, this boils down to a very simple question (modulo >>>>>>> Chris's point): Either choice will surprise some users. Which surprise >>>>>>> is worse? Personally, I'd always prefer correct but slow behavior by >>>>>>> default, and explicitly enabling dangerous (but in some cases fast) >>>>>>> behavior. >>>>>> >>>>>> The behavior is only dangerous because people are using it in new and >>>>>> different ways. >>>>> >>>>> I'd point out that reid thought he made the JIT thread-safe in r22404 >>>>> back in 2005. Calling it from multiple threads isn't new and >>>>> different, it's just subtly broken. I suggested changing the default >>>>> because most people who run into this problem don't think they're >>>>> doing anything unusual, and in fact their code works fine with the >>>>> eager JIT. People shouldn't stumble into broken behavior, and defaults >>>>> are good to prevent stumbling. >>>>> >>>>> To avoid misconceptions, Unladen Swallow added the line to turn off >>>>> the lazy jit months ago, and we'll keep that line whatever the >>>>> decision is here. We might take advantage of a thread-safe >>>>> code-patching facility eventually, but we've been designing assuming >>>>> nobody else will implement that for us. I favor changing the default >>>>> because it'll help newbies, not because we need it for anything. >>>>> >>>>>>> I would also point out that it seems that most of the people new to >>>>>>> the JIT are surprised by the current behavior, where as those who >>>>>>> would be surprised by needing to enable lazy JIT are those long >>>>>>> familiar with past behavior. In the OSS world, I always favor easing >>>>>>> adoption over maintaining the status quo. >>>>>> >>>>>> This argues for better documentation. I'd prefer for EE to abort if user >>>>>> is asking for a known dangerous configuration (multi-threaded and lazy). >>>>> >>>>> I think that'd be a decent fix for the thread-safety problem. It'd >>>>> require an extra check on each call to runJITOnFunctionUnlocked since >>>>> laziness is set by a call, not on construction. Or, we could use the >>>>> JIT lock to assert that it's never entered concurrently. On the other >>>>> hand, Nicolas Geoffray objected when I suggested that in the bug. >>>>> >>>>>> The biggest argument I have for staying with lazy is llvm JIT is not a >>>>>> light weight JIT. It's designed to do all the codegen optimizations a normal >>>>>> static compiler would do. Non-lazy JIT is too slow. >>>>> >>>>> ?scar used the cost of the JIT as an argument _against_ the lazy JIT. >>>>> Could you elaborate on why you think it's an argument in favor of lazy >>>>> JITting? >>>>> >>>>>> I'd prefer not to change the behavior. >>>>> >>>>> I'm guessing, based on your vagueness, that there are some internal >>>>> single-threaded Apple users who think that the lazy JIT is the best >>>>> performing option for them and who don't want to add a line to their >>>>> apps overriding the default. But it's hard for me or anyone else >>>>> outside Apple to judge whether they ought to drive the default without >>>>> a little more information about why the lazy JIT is good for them. >>>>> Could you describe any features of their use that make the lazy JIT a >>>>> good idea for them? >>>>> >>>>>> If we want to start using it in new and interesting ways, we should just >>>>>> design a new JIT. >>>>> >>>>>>> My meager 2 cents. >>>>>>> -Chandler >>>>>>> >>>>>>> On Wed, Oct 28, 2009 at 9:41 AM, Jeffrey Yasskin >>>>>>> wrote: >>>>>>>> >>>>>>>> In r85295, in response to the discussion at http://llvm.org/PR5184 >>>>>>>> (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to >>>>>>>> non-lazy. It has since come to my attention that this may have been >>>>>>>> the wrong change, so I wanted to ask you guys. >>>>>>>> >>>>>>>> A couple reasons to make the default non-lazy compilation: >>>>>>>> * The lack of thread-safety surprises new users >>>>>>>> * Crashes due to this will be rare and so hard to track down >>>>>>>> * The current lazy scheme is almost never the right answer for >>>>>>>> performance >>>>>>>> * It's only one line of code to turn on lazy compilation when it is >>>>>>>> the right answer for you. >>>>>>>> >>>>>>>> And a couple to default to lazy compilation: >>>>>>>> * It's safe for single-threaded code. >>>>>>>> * There are existing users who have assumed this default. >>>>>>>> * PPC and ARM don't support non-lazy compilation yet (the tests >>>>>>>> currently run the lazy jit). >>>>>>>> * Gratuitous changes are bad. >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> We can choose the default for lli separately from the JIT's default if >>>>>>>> we want. >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>>> >>>> >>>> >> >> > From mdevan.foobar at gmail.com Sun Nov 1 01:15:10 2009 From: mdevan.foobar at gmail.com (Mahadevan R) Date: Sun, 1 Nov 2009 12:45:10 +0530 Subject: [LLVMdev] Something wrong with my libpthread.so In-Reply-To: <4AED2FEA.8030205@mxc.ca> References: <4AED2FEA.8030205@mxc.ca> Message-ID: On Sun, Nov 1, 2009 at 12:21 PM, Nick Lewycky wrote: > Mahadevan R wrote: >> >> Hi, >> >> On Sat, Oct 31, 2009 at 11:42 AM, Nan Zhu wrote: >>> >>> Hi,all >>> >>> I tried to run the generated whole-program bitcode of BIND,but I got some >>> information: >>> >>> 0 ? lli ? ? ? ? ? ? 0x0000000000feda16 >>> 1 ? lli ? ? ? ? ? ? 0x0000000000fed88f >>> 2 ? libpthread.so.0 0x0000003df340eee0 >>> 3 ? libc.so.6 ? ? ? 0x0000003df28332f5 gsignal + 53 >>> 4 ? libc.so.6 ? ? ? 0x0000003df2834b20 abort + 384 >>> 5 ? libc.so.6 ? ? ? 0x0000003df282c2fa __assert_fail + 234 >>> 6 ? lli ? ? ? ? ? ? 0x000000000085ece9 >>> llvm::SmallVectorImpl::operator[](unsigned int) + 77 >>> 7 ? lli ? ? ? ? ? ? 0x0000000000850ce0 >>> llvm::BitcodeReader::ParseMetadataAttachment() + 448 >>> 8 ? lli ? ? ? ? ? ? 0x0000000000851043 >> >> Looks like a bug in the following piece of code, from >> BitcodeReader::ParseMetadataAttachment(): >> >> ?1601 ? ? ?case bitc::METADATA_ATTACHMENT: { >> ?1602 ? ? ? ?unsigned RecordLength = Record.size(); >> ?1603 ? ? ? ?if (Record.empty() || (RecordLength - 1) % 2 == 1) >> ?1604 ? ? ? ? ?return Error ("Invalid METADATA_ATTACHMENT reader!"); >> ?1605 ? ? ? ?Instruction *Inst = InstructionList[Record[0]]; >> ?1606 ? ? ? ?for (unsigned i = 1; i != RecordLength; i = i+2) { >> ?1607 ? ? ? ? ?unsigned Kind = Record[i]; >> ?1608 ? ? ? ? ?Value *Node = MDValueList.getValueFwdRef(Record[i+1]); >> ?1609 ? ? ? ? ?TheMetadata.addMD(Kind, cast(Node), Inst); >> ?1610 ? ? ? ?} >> ?1611 ? ? ? ?break; >> ?1612 ? ? ?} >> >> At line 1606, i never becomes equal to RecordLength. > > I strongly suspect this is llvm.org/PR5278 . Please add your comments there, > thanks! Done. Regards, -Mahadevan. > > Nick > From edwintorok at gmail.com Sun Nov 1 03:53:51 2009 From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=) Date: Sun, 01 Nov 2009 11:53:51 +0200 Subject: [LLVMdev] Should LLVM JIT default to lazy or non-lazy? In-Reply-To: References:

<0A272AD2-24B8-4FF6-8F0C-3A291CE5DBBE@apple.com> <4AEA0971.6020803@lip6.fr> <4AEAAECE.3040102@gmail.com> Message-ID: <4AED5AAF.9030202@gmail.com> On 2009-11-01 08:40, Jeffrey Yasskin wrote: > 2009/10/30 T?r?k Edwin : > >> On 2009-10-29 23:55, Jeffrey Yasskin wrote: >> >>> On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray >>> wrote: >>> >>> >>>> Hi Jeffrey, >>>> >>>> Jeffrey Yasskin wrote: >>>> >>>> >>>>> Cool, I'll start implementing it. >>>>> >>>>> >>>>> >>>> Great! Thanks. >>>> >>>> Just to clarify things: on my end, it doesn't really matter what is the >>>> default behavior, as long as vmkit can continue to have the existing >>>> behavior of lazy compilation. With Chris' solution, I was wondering how you >>>> would implement the getPointerToFunction{Eager, Lazy} functions when the >>>> getPointerToFunction is called by the JIT, not the user. For example, when >>>> Function F calls Function G and the JIT needs an address for G (either a >>>> callback or the function address), how will it know if it must call >>>> getPointerToFunctionEager or getPointerToFunctionLazy? Do you plan on >>>> continuing having a flag that enables/disables lazy compilation and poll >>>> this flag on each function call? How is that different than the existing >>>> system? >>>> >>>> >>> Semantically, I'll thread the flag through all the calls that may >>> eventually need to recursively call getPointerToFunction. To implement >>> that without having to modify lots of calls, I'll probably replace the >>> current public default eager/lazy setting with a private flag with >>> values {Unknown, Lazy, Eager}, set it on entry and exit of >>> getPointerToFunction, and check it on each internal recursive call. >>> The difference with the current system is that the user is forced to >>> set the flag to their desired value whenever they call into the JIT, >>> rather than relying on a default. That choice then propagates through >>> the whole recursive tree of codegens, without affecting the next tree. >>> >>> Note that I'm using getPointerToFunction as an abbreviation for the >>> 3ish public functions that'll need to take this option. >>> >> The documentation should also be updated >> (http://llvm.org/docs/ProgrammersManual.html#threading) to reflect what >> one needs to do, >> to ensure thread-safe JITing. >> > > Thanks for that reminder. I've updated it in the patch I'm about to > mail, but I should apply the update regardless of whether the rest of > the patch goes in. > > >> Also does every JIT target support non-lazy JITing now? See PR4816, >> last time I checked (r83242) it only worked on X86, and failed on PPC; >> so I had to keep lazy JITing enabled even if its not what I want for >> many reasons. >> > > It's still the case that only X86 supports eager jitting. It doesn't > look that hard to add it to the rest of the targets though. > > Ok. >> Also perhaps the lazy compilation stub should spin waiting on a lock >> (implemented using atomics), and the compilation callback should >> execute while holding the lock just before patching the callsite, so it >> would look like this in pseudocode: >> > > Good idea. This increases the code size a bit, but it's clearly better > than the "load the target address" option I mentioned in the bug. > Would you add it to the bug so we don't lose it? > > I think we can put the entire "not yet patched" branch inside the > compilation callback to minimize the code size impact: > > callsite_patch_state = 0;// for each callsite one byte of memory > > callsite: > if (atomic_load(&callsite_patch_state) != 2) { > call CompilationCallback // Doesn't return until the patchsite is patched. > } > //fast- and slow-path: already compiled and patched > patchsite: > call // will be patched > > Yes, that sounds good (except that we'd want a jmp instead of a call I think), I'll post a patch to that bugreport tomorrow if time permits. Would this mean that lazy-JITing would be threadsafe and the default could stay lazy? Best regards, --Edwin From jyasskin at google.com Sun Nov 1 12:02:31 2009 From: jyasskin at google.com (Jeffrey Yasskin) Date: Sun, 1 Nov 2009 11:02:31 -0700 Subject: [LLVMdev] Should LLVM JIT default to lazy or non-lazy? In-Reply-To: <4AED5AAF.9030202@gmail.com> References:

<0A272AD2-24B8-4FF6-8F0C-3A291CE5DBBE@apple.com> <4AEA0971.6020803@lip6.fr> <4AEAAECE.3040102@gmail.com> <4AED5AAF.9030202@gmail.com> Message-ID: 2009/11/1 T?r?k Edwin : > On 2009-11-01 08:40, Jeffrey Yasskin wrote: >> 2009/10/30 T?r?k Edwin : >> >>> On 2009-10-29 23:55, Jeffrey Yasskin wrote: >>> >>>> On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray >>>> wrote: >>>> >>>> >>>>> Hi Jeffrey, >>>>> >>>>> Jeffrey Yasskin wrote: >>>>> >>>>> >>>>>> Cool, I'll start implementing it. >>>>>> >>>>>> >>>>>> >>>>> Great! Thanks. >>>>> >>>>> Just to clarify things: on my end, it doesn't really matter what is the >>>>> default behavior, as long as vmkit can continue to have the existing >>>>> behavior of lazy compilation. With Chris' solution, I was wondering how you >>>>> would implement the getPointerToFunction{Eager, Lazy} functions when the >>>>> getPointerToFunction is called by the JIT, not the user. For example, when >>>>> Function F calls Function G and the JIT needs an address for G (either a >>>>> callback or the function address), how will it know if it must call >>>>> getPointerToFunctionEager or getPointerToFunctionLazy? Do you plan on >>>>> continuing having a flag that enables/disables lazy compilation and poll >>>>> this flag on each function call? How is that different than the existing >>>>> system? >>>>> >>>>> >>>> Semantically, I'll thread the flag through all the calls that may >>>> eventually need to recursively call getPointerToFunction. To implement >>>> that without having to modify lots of calls, I'll probably replace the >>>> current public default eager/lazy setting with a private flag with >>>> values {Unknown, Lazy, Eager}, set it on entry and exit of >>>> getPointerToFunction, and check it on each internal recursive call. >>>> The difference with the current system is that the user is forced to >>>> set the flag to their desired value whenever they call into the JIT, >>>> rather than relying on a default. That choice then propagates through >>>> the whole recursive tree of codegens, without affecting the next tree. >>>> >>>> Note that I'm using getPointerToFunction as an abbreviation for the >>>> 3ish public functions that'll need to take this option. >>>> >>> The documentation should also be updated >>> (http://llvm.org/docs/ProgrammersManual.html#threading) to reflect what >>> one needs to do, >>> to ensure thread-safe JITing. >>> >> >> Thanks for that reminder. I've updated it in the patch I'm about to >> mail, but I should apply the update regardless of whether the rest of >> the patch goes in. >> >> >>> Also does every JIT target support non-lazy JITing now? ?See PR4816, >>> last time I checked (r83242) it only worked on X86, and failed on PPC; >>> so I had to keep lazy JITing enabled even if its not what I want for >>> many reasons. >>> >> >> It's still the case that only X86 supports eager jitting. It doesn't >> look that hard to add it to the rest of the targets though. >> >> > > Ok. > >>> Also perhaps the lazy compilation stub should spin waiting on a lock >>> (implemented using atomics), and the compilation callback should >>> execute while holding the lock just before patching the callsite, so it >>> would look like this in pseudocode: >>> >> >> Good idea. This increases the code size a bit, but it's clearly better >> than the "load the target address" option I mentioned in the bug. >> Would you add it to the bug so we don't lose it? >> >> I think we can put the entire "not yet patched" branch inside the >> compilation callback to minimize the code size impact: >> >> callsite_patch_state = 0;// for each callsite one byte of memory >> >> callsite: >> if ?(atomic_load(&callsite_patch_state) != 2) { >> ? call CompilationCallback ?// Doesn't return until the patchsite is patched. >> } >> //fast- and slow-path: already compiled and patched >> patchsite: >> ? ? ? call // will be patched >> >> > > Yes, that sounds good (except that we'd want a jmp instead of a call I > think), I'll post a patch to that bugreport tomorrow if time permits. > > Would this mean that lazy-JITing would be threadsafe and the default > could stay lazy? If lazy jitting were threadsafe, I'd stop pushing to make eager jitting the default. Do you mean you're volunteering to implement thread-safe lazy jitting? If so, remember to fix the places that patch non-stub calls too. Thanks! From ngompa13 at gmail.com Sun Nov 1 15:10:00 2009 From: ngompa13 at gmail.com (King InuYasha) Date: Sun, 1 Nov 2009 15:10:00 -0600 Subject: [LLVMdev] Issue compiling LLVM 2.6 on Windows with MinGW Message-ID: <8278b1b0911011310j2d235d63iefd7e28585d9d49c@mail.gmail.com> Hello, I downloaded LLVM 2.6 and was attempting to compile it with TDM-GCC 4.4.1-tdm2-sjlj + cmake 2.6.4 and this happened: =============Console=================== C:\projects\game-editor\LLVM\build-root>mingw32-make [ 2%] Built target LLVMSystem [ 5%] Built target LLVMSupport [ 7%] Built target tblgen [ 7%] Built target intrinsics_gen [ 10%] Built target LLVMCore [ 12%] Built target LLVMTransformUtils [ 15%] Built target LLVMScalarOpts [ 22%] Built target LLVMCodeGen [ 26%] Built target LLVMAnalysis [ 26%] Built target LLVMAsmPrinter [ 29%] Built target LLVMSelectionDAG [ 30%] Built target LLVMBitReader [ 31%] Built target LLVMBitWriter [ 32%] Built target LLVMInstrumentation [ 36%] Built target LLVMipo [ 36%] Built target LLVMHello [ 36%] Built target LLVMLinker [ 36%] Built target LLVMipa [ 38%] Built target LLVMMC [ 38%] Built target FileCheck [ 40%] Built target ARMCodeGenTable_gen [ 44%] Built target LLVMARMCodeGen [ 45%] Built target LLVMARMInfo [ 45%] Built target LLVMARMAsmPrinter [ 45%] Built target LLVMCBackend [ 45%] Built target LLVMCBackendInfo [ 45%] Built target LLVMCppBackend [ 45%] Built target LLVMCppBackendInfo [ 47%] Built target MipsCodeGenTable_gen [ 50%] Built target LLVMMipsCodeGen [ 50%] Built target LLVMMipsInfo [ 50%] Built target LLVMMipsAsmPrinter [ 50%] Built target LLVMMSIL [ 50%] Built target LLVMMSILInfo [ 52%] Built target PowerPCCodeGenTable_gen [ 56%] Built target LLVMPowerPCCodeGen [ 56%] Built target LLVMPowerPCInfo [ 56%] Built target LLVMPowerPCAsmPrinter [ 58%] Built target X86CodeGenTable_gen [ 62%] Built target LLVMX86CodeGen [ 63%] Built target LLVMX86Info [ 63%] Built target LLVMX86AsmPrinter [ 63%] Built target LLVMX86AsmParser [ 63%] Built target LLVMExecutionEngine [ 64%] Built target LLVMInterpreter [ 64%] Built target LLVMJIT [ 67%] Built target LLVMTarget [ 67%] Built target LLVMAsmParser [ 68%] Built target LLVMDebugger [ 68%] Built target LLVMArchive Linking CXX executable ..\..\bin\opt.exe ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x25): undefined r eference to `_imp__pthread_rwlockattr_init' ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x5f): undefined r eference to `_imp__pthread_rwlockattr_setpshared' ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x76): undefined r eference to `_imp__pthread_rwlock_init' ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0xa8): undefined r eference to `_imp__pthread_rwlockattr_destroy' ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x103): undefined reference to `_imp__pthread_rwlockattr_init' ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x13d): undefined reference to `_imp__pthread_rwlockattr_setpshared' ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x154): undefined reference to `_imp__pthread_rwlock_init' ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x186): undefined reference to `_imp__pthread_rwlockattr_destroy' ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x1f3): undefined reference to `_imp__pthread_rwlock_destroy' ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x23d): undefined reference to `_imp__pthread_rwlock_destroy' ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x287): undefined reference to `_imp__pthread_rwlock_rdlock' ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x2d1): undefined reference to `_imp__pthread_rwlock_unlock' ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x31b): undefined reference to `_imp__pthread_rwlock_wrlock' ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x365): undefined reference to `_imp__pthread_rwlock_unlock' ..\..\lib\libLLVMSystem.a(ThreadLocal.cpp.obj):ThreadLocal.cpp:(.text+0x37): und efined reference to `_imp__pthread_key_create' ..\..\lib\libLLVMSystem.a(ThreadLocal.cpp.obj):ThreadLocal.cpp:(.text+0xa5): und efined reference to `_imp__pthread_key_create' ..\..\lib\libLLVMSystem.a(ThreadLocal.cpp.obj):ThreadLocal.cpp:(.text+0xfd): und efined reference to `_imp__pthread_key_delete' ..\..\lib\libLLVMSystem.a(ThreadLocal.cpp.obj):ThreadLocal.cpp:(.text+0x16b): un defined reference to `_imp__pthread_key_delete' ..\..\lib\libLLVMSystem.a(ThreadLocal.cpp.obj):ThreadLocal.cpp:(.text+0x1d9): un defined reference to `_imp__pthread_key_delete' ..\..\lib\libLLVMSystem.a(ThreadLocal.cpp.obj):ThreadLocal.cpp:(.text+0x245): un defined reference to `_imp__pthread_setspecific' ..\..\lib\libLLVMSystem.a(ThreadLocal.cpp.obj):ThreadLocal.cpp:(.text+0x28a): un defined reference to `_imp__pthread_getspecific' collect2: ld returned 1 exit status mingw32-make[2]: *** [bin/opt.exe] Error 1 mingw32-make[1]: *** [tools/opt/CMakeFiles/opt.dir/all] Error 2 mingw32-make: *** [all] Error 2 C:\projects\game-editor\LLVM\build-root> =======End console=========== The pthread libraries are there, so what's going on? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091101/db8c4f36/attachment.html From evan.cheng at apple.com Sun Nov 1 16:27:30 2009 From: evan.cheng at apple.com (Evan Cheng) Date: Sun, 1 Nov 2009 14:27:30 -0800 Subject: [LLVMdev] Should LLVM JIT default to lazy or non-lazy? In-Reply-To: References: <74c447500910281007t527c2e3cvbd6ff1335f290056@mail.gmail.com>

<0A272AD2-24B8-4FF6-8F0C-3A291CE5DBBE@apple.com> Message-ID: <12DE512F-09A9-4516-A23F-0543118A06C8@apple.com> On Nov 1, 2009, at 12:09 AM, Jeffrey Yasskin wrote: > A possible patch implementing this is at > http://codereview.appspot.com/144074 > (http://codereview.appspot.com/download/issue144074_1.diff). > > I do NOT think we should accept this patch: It changes a lot of APIs > and makes users specify the choice in many places, while I think most > users really just want one choice for their whole app. There's a good > argument to be made that users may want to decide certain calls should > be lazily-compiled, but those are boundaries _within_ a transitive > call tree, not the whole-tree choice this change allows. I'd be happy > with a forced choice when creating the JIT, or with an optional choice > defaulted to the safer option, but this patch seems like the wrong > thing to do. > > Evan, you wrote, "there are existing customers out there that are > using previous llvm release who will not appreciate the API change." > Who are they? Recall that after my original change they can get back > to lazy compilation by adding jit->DisableLazyCompilation(false) to > their code. They have no need for #ifdefs. I know of several that are not actively participating in these discussions. I don't have knowledge of how they are using LLVM JIT now nor do I think that's appropriate for me to say anything. There are probably other clients that we don't know about. I guess changing API is one way to encourage folks from participating in these discussions. I honestly don't know what the best solution is. I am leaving it to those of you who are actively hacking on the JIT to decide. Evan > > I still think that having a default that's right in nearly all cases > is the best option (the only concrete counter-example I've seen is > lli), but I'm happy to write another patch with a global forced choice > or commit this one if that's what you guys want. > > On Thu, Oct 29, 2009 at 11:46 AM, Jeffrey Yasskin > wrote: >> Cool, I'll start implementing it. >> >> Thanks all for the decision! >> >> On Thu, Oct 29, 2009 at 11:03 AM, Evan Cheng >> wrote: >>> I have no objection to Chris' proposal. >>> >>> Evan >>> >>> On Oct 29, 2009, at 9:45 AM, Jeffrey Yasskin wrote: >>> >>>> Are you objecting to Chris's proposal? I was waiting to implement >>>> it >>>> until you replied so I wouldn't have to implement two things. I >>>> disagree with a lot of what you wrote below, but it's not worth >>>> arguing about if there's a compromise we can both live with. >>>> >>>> On Thu, Oct 29, 2009 at 12:36 AM, Evan Cheng >>>> wrote: >>>>> There is nothing here that prevents users from enabling or >>>>> disabling lazy >>>>> JIT. We're talk about flipping the default behavior. That does >>>>> not make the >>>>> API any better or worse. Nor does it fix the inherent thread >>>>> safety issue. >>>>> >>>>> I can tell you there are no Apple clients that depend on the >>>>> lazy JIT. >>>>> Please do not imply I am being secretive. I am simply busy. My >>>>> objection is >>>>> simple. Changing API simply for the sake of flipping default >>>>> behavior does >>>>> not seem like a good trade off to me. You may not feel the pain, >>>>> but there >>>>> are existing customers out there that are using previous llvm >>>>> release who >>>>> will not appreciate the API change. >>>>> >>>>> To me, the decision is simple. People who have done the work in >>>>> the past >>>>> have made their choices. We better respect their choices unless >>>>> we are >>>>> replacing them with something better. Flipping the default isn't >>>>> better. If >>>>> someone wants to sign up to design a new API, that person(s) get >>>>> to decide >>>>> on the default behavior. It's simple as that. >>>>> >>>>> For behavior / API change like this, we better extend llvm- >>>>> config (or some >>>>> other means) to expose that information. So the existing clients >>>>> can at >>>>> least ifdef the code. >>>>> >>>>> Evan >>>>> >>>>> On Oct 28, 2009, at 1:31 PM, Jeffrey Yasskin wrote: >>>>> >>>>>> On Wed, Oct 28, 2009 at 12:21 PM, Evan Cheng >>>>> > wrote: >>>>>>> >>>>>>> On Oct 28, 2009, at 10:07 AM, Chandler Carruth wrote: >>>>>>> >>>>>>>> From where I sit, this boils down to a very simple question >>>>>>>> (modulo >>>>>>>> Chris's point): Either choice will surprise some users. Which >>>>>>>> surprise >>>>>>>> is worse? Personally, I'd always prefer correct but slow >>>>>>>> behavior by >>>>>>>> default, and explicitly enabling dangerous (but in some cases >>>>>>>> fast) >>>>>>>> behavior. >>>>>>> >>>>>>> The behavior is only dangerous because people are using it in >>>>>>> new and >>>>>>> different ways. >>>>>> >>>>>> I'd point out that reid thought he made the JIT thread-safe in >>>>>> r22404 >>>>>> back in 2005. Calling it from multiple threads isn't new and >>>>>> different, it's just subtly broken. I suggested changing the >>>>>> default >>>>>> because most people who run into this problem don't think they're >>>>>> doing anything unusual, and in fact their code works fine with >>>>>> the >>>>>> eager JIT. People shouldn't stumble into broken behavior, and >>>>>> defaults >>>>>> are good to prevent stumbling. >>>>>> >>>>>> To avoid misconceptions, Unladen Swallow added the line to turn >>>>>> off >>>>>> the lazy jit months ago, and we'll keep that line whatever the >>>>>> decision is here. We might take advantage of a thread-safe >>>>>> code-patching facility eventually, but we've been designing >>>>>> assuming >>>>>> nobody else will implement that for us. I favor changing the >>>>>> default >>>>>> because it'll help newbies, not because we need it for anything. >>>>>> >>>>>>>> I would also point out that it seems that most of the people >>>>>>>> new to >>>>>>>> the JIT are surprised by the current behavior, where as those >>>>>>>> who >>>>>>>> would be surprised by needing to enable lazy JIT are those long >>>>>>>> familiar with past behavior. In the OSS world, I always favor >>>>>>>> easing >>>>>>>> adoption over maintaining the status quo. >>>>>>> >>>>>>> This argues for better documentation. I'd prefer for EE to >>>>>>> abort if user >>>>>>> is asking for a known dangerous configuration (multi-threaded >>>>>>> and lazy). >>>>>> >>>>>> I think that'd be a decent fix for the thread-safety problem. >>>>>> It'd >>>>>> require an extra check on each call to runJITOnFunctionUnlocked >>>>>> since >>>>>> laziness is set by a call, not on construction. Or, we could >>>>>> use the >>>>>> JIT lock to assert that it's never entered concurrently. On the >>>>>> other >>>>>> hand, Nicolas Geoffray objected when I suggested that in the bug. >>>>>> >>>>>>> The biggest argument I have for staying with lazy is llvm JIT >>>>>>> is not a >>>>>>> light weight JIT. It's designed to do all the codegen >>>>>>> optimizations a normal >>>>>>> static compiler would do. Non-lazy JIT is too slow. >>>>>> >>>>>> ?scar used the cost of the JIT as an argument _against_ the >>>>>> lazy JIT. >>>>>> Could you elaborate on why you think it's an argument in favor >>>>>> of lazy >>>>>> JITting? >>>>>> >>>>>>> I'd prefer not to change the behavior. >>>>>> >>>>>> I'm guessing, based on your vagueness, that there are some >>>>>> internal >>>>>> single-threaded Apple users who think that the lazy JIT is the >>>>>> best >>>>>> performing option for them and who don't want to add a line to >>>>>> their >>>>>> apps overriding the default. But it's hard for me or anyone else >>>>>> outside Apple to judge whether they ought to drive the default >>>>>> without >>>>>> a little more information about why the lazy JIT is good for >>>>>> them. >>>>>> Could you describe any features of their use that make the lazy >>>>>> JIT a >>>>>> good idea for them? >>>>>> >>>>>>> If we want to start using it in new and interesting ways, we >>>>>>> should just >>>>>>> design a new JIT. >>>>>> >>>>>>>> My meager 2 cents. >>>>>>>> -Chandler >>>>>>>> >>>>>>>> On Wed, Oct 28, 2009 at 9:41 AM, Jeffrey Yasskin >>>>>>> > >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> In r85295, in response to the discussion at http://llvm.org/PR5184 >>>>>>>>> (Lazy JIT ain't thread-safe), I changed the default JIT from >>>>>>>>> lazy to >>>>>>>>> non-lazy. It has since come to my attention that this may >>>>>>>>> have been >>>>>>>>> the wrong change, so I wanted to ask you guys. >>>>>>>>> >>>>>>>>> A couple reasons to make the default non-lazy compilation: >>>>>>>>> * The lack of thread-safety surprises new users >>>>>>>>> * Crashes due to this will be rare and so hard to track down >>>>>>>>> * The current lazy scheme is almost never the right answer for >>>>>>>>> performance >>>>>>>>> * It's only one line of code to turn on lazy compilation >>>>>>>>> when it is >>>>>>>>> the right answer for you. >>>>>>>>> >>>>>>>>> And a couple to default to lazy compilation: >>>>>>>>> * It's safe for single-threaded code. >>>>>>>>> * There are existing users who have assumed this default. >>>>>>>>> * PPC and ARM don't support non-lazy compilation yet (the >>>>>>>>> tests >>>>>>>>> currently run the lazy jit). >>>>>>>>> * Gratuitous changes are bad. >>>>>>>>> >>>>>>>>> Thoughts? >>>>>>>>> >>>>>>>>> We can choose the default for lli separately from the JIT's >>>>>>>>> default if >>>>>>>>> we want. >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> >> From evan.cheng at apple.com Sun Nov 1 16:33:48 2009 From: evan.cheng at apple.com (Evan Cheng) Date: Sun, 1 Nov 2009 14:33:48 -0800 Subject: [LLVMdev] JIT and security In-Reply-To: References: Message-ID: Check out professor Saman Amarasinghe's work. It was being commercialized by a company called Determina (which has since been acquired by VMWare). Evan On Oct 18, 2009, at 1:46 PM, Oleg Knut wrote: > Hello, > > I'm writing JIT compiler that will run a third party code. My goal is > to build it with security layer that will allow me to prevent some > basic operation that possibly can harm JIT application host computer. > > Maybe some of you can guide me on how to do following operations: > 1) prevent system calls > 2) memory allocation management (set some limits that can't be used > by JIT) > 3) CPU power limiting > > I have a guess on how to prevent system calls or some known function > calls by parsing IR and picking up functions calls that maybe > unwanted. Another way is to check list of functions in object model. > Maybe there is already implemented mechanism like that. So, anyone > could give me a clue. > > About RAM and CPU management I have no idea how to do that. > > Ideally my JIT compiler have to become a BlackBox, that hosting party > can configure to his needs. > > I hope I can find some help here. That would be great! > > Thank you for your time, > Oleg. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091101/bd131c26/attachment.html From ofv at wanadoo.es Sun Nov 1 19:04:44 2009 From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=) Date: Mon, 02 Nov 2009 02:04:44 +0100 Subject: [LLVMdev] Issue compiling LLVM 2.6 on Windows with MinGW References: <8278b1b0911011310j2d235d63iefd7e28585d9d49c@mail.gmail.com> Message-ID: <87d441ag9f.fsf@telefonica.net> King InuYasha writes: > I downloaded LLVM 2.6 and was attempting to compile it with TDM-GCC > 4.4.1-tdm2-sjlj + cmake 2.6.4 and this happened: [snip] > Linking CXX executable ..\..\bin\opt.exe > ..\..\lib\libLLVMSystem.a(RWMutex.cpp.obj):RWMutex.cpp:(.text+0x25): > undefined reference to `_imp__pthread_rwlockattr_init' [snip] > The pthread libraries are there, so what's going on? For this issues, bug reports are more convenient than messages on the mailing list, so please file a bug report and put my e-mail on its CC list. Please execute mingw32-make VERBOSE=1 and show the link command for opt.exe -- ?scar From atomicdog.jwm at gmail.com Mon Nov 2 00:57:18 2009 From: atomicdog.jwm at gmail.com (John Myers) Date: Sun, 1 Nov 2009 22:57:18 -0800 Subject: [LLVMdev] llvm-mc build fails Message-ID: <91226b40911012257o5535f413o3094bb2cef34310b@mail.gmail.com> Hi, I'm looking for some pointers on how to troubleshoot this problem. I'm trying to write a backend for the AVR. There is an undefined reference at line 48 which is the line FrameInfo() is on. I've tried to use the MSP430 and other targets as references so I'm not sure what changes I did would cause a problem on this line? AVRTargetMachine::AVRTargetMachine(const Target &T, const std::string &TT, const std::string &FS) : LLVMTargetMachine(T, TT), Subtarget(TT, FS), DataLayout("e-p:16:8:8-i8:8:8-i16:8:8-i32:8:8"), InstrInfo(Subtarget), TLInfo(*this), FrameInfo(TargetFrameInfo::StackGrowsDown, 1, 0) { } Linking CXX executable ../../bin/llvm-mc cd /home/john/src/llvm_build/tools/llvm-mc && /usr/bin/cmake -E cmake_link_script CMakeFiles/llvm-mc.dir/link.txt --verbose=1 /usr/bin/c++ -g -fPIC CMakeFiles/llvm-mc.dir/llvm-mc.cpp.o CMakeFiles/llvm-mc.dir/AsmExpr.cpp.o CMakeFiles/llvm-mc.dir/AsmLexer.cpp.o CMakeFiles/llvm-mc.dir/AsmParser.cpp.o -o ../../bin/llvm-mc -rdynamic ../../lib/libLLVMAVRCodeGen.a ../../lib/libLLVMAVRAsmPrinter.a ../../lib/libLLVMAVRInfo.a ../../lib/libLLVMMC.a ../../lib/libLLVMSupport.a ../../lib/libLLVMSystem.a -ldl ../../lib/libLLVMSelectionDAG.a ../../lib/libLLVMAnalysis.a ../../lib/libLLVMAsmPrinter.a ../../lib/libLLVMCodeGen.a ../../lib/libLLVMCore.a ../../lib/libLLVMScalarOpts.a ../../lib/libLLVMTransformUtils.a ../../lib/libLLVMSupport.a ../../lib/libLLVMSystem.a ../../lib/libLLVMAVRCodeGen.a(AVRTargetMachine.cpp.o): In function `AVRTargetMachine': /home/john/src/llvm2.6/lib/Target/AVR/AVRTargetMachine.cpp:48: undefined reference to `llvm::TargetData::~TargetData()' /home/john/src/llvm2.6/lib/Target/AVR/AVRTargetMachine.cpp:48: undefined reference to `llvm::TargetData::~TargetData()' ../../lib/libLLVMAVRCodeGen.a(AVRTargetMachine.cpp.o): In function `TargetFrameInfo': /home/john/src/llvm2.6/include/llvm/Target/TargetFrameInfo.h:40: undefined reference to `vtable for llvm::TargetFrameInfo' ../../lib/libLLVMAVRCodeGen.a(AVRTargetMachine.cpp.o): In function `~AVRGenRegisterInfo': /home/john/src/llvm_build/lib/Target/AVR/AVRGenRegisterInfo.h.inc:14: undefined reference to `llvm::TargetRegisterInfo::~TargetRegisterInfo()' ../../lib/libLLVMAVRCodeGen.a(AVRTargetMachine.cpp.o): In function `~TargetInstrInfoImpl': /home/john/src/llvm2.6/include/llvm/Target/TargetInstrInfo.h:474: undefined reference to `llvm::TargetInstrInfo::~TargetInstrInfo()' ../../lib/libLLVMAVRCodeGen.a(AVRTargetMachine.cpp.o): In function `~AVRSubtarget': /home/john/src/llvm2.6/lib/Target/AVR/AVRSubtarget.h:24: undefined reference to `llvm::TargetSubtarget::~TargetSubtarget()' /home/john/src/llvm2.6/lib/Target/AVR/AVRSubtarget.h:24: undefined reference to `llvm::TargetSubtarget::~TargetSubtarget()' ../../lib/libLLVMAVRCodeGen.a(AVRTargetMachine.cpp.o): In function `~LLVMTargetMachine': /home/john/src/llvm2.6/include/llvm/Target/TargetMachine.h:285: undefined reference to `llvm::TargetMachine::~TargetMachine()' ../../lib/libLLVMAVRCodeGen.a(AVRTargetMachine.cpp.o): In function `~AVRTargetMachine': /home/john/src/llvm2.6/lib/Target/AVR/AVRTargetMachine.h:31: undefined reference to `llvm::TargetFrameInfo::~TargetFrameInfo()' /home/john/src/llvm2.6/lib/Target/AVR/AVRTargetMachine.h:31: undefined reference to `llvm::TargetData::~TargetData()' /home/john/src/llvm2.6/lib/Target/AVR/AVRTargetMachine.h:31: undefined reference to `llvm::TargetData::~TargetData()' /home/john/src/llvm2.6/lib/Target/AVR/AVRTargetMachine.h:31: undefined reference to `llvm::TargetFrameInfo::~TargetFrameInfo()' /home/john/src/llvm2.6/lib/Target/AVR/AVRTargetMachine.h:31: undefined reference to `llvm::TargetData::~TargetData()' /home/john/src/llvm2.6/lib/Target/AVR/AVRTargetMachine.h:31: undefined reference to `llvm::TargetData::~TargetData()' -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091101/090a0b87/attachment.html From anton at korobeynikov.info Mon Nov 2 01:31:09 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Mon, 2 Nov 2009 10:31:09 +0300 Subject: [LLVMdev] llvm-mc build fails In-Reply-To: <91226b40911012257o5535f413o3094bb2cef34310b@mail.gmail.com> References: <91226b40911012257o5535f413o3094bb2cef34310b@mail.gmail.com> Message-ID: Hello, John > There is an undefined reference at line 48 which is the line FrameInfo() is > on. I've tried to use the MSP430 and other targets as references so I'm not > sure > what changes I did would cause a problem on this line? It doesn't seem you're linking libTarget in. Have you tried not to use cmake-generated makefiles? As for the cmake - it tracked the explicit list of dependencies somewhere, you might want to update it as well (and different target-specific places in CMakeList.txt files). -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From gjhe at novell.com Mon Nov 2 02:45:04 2009 From: gjhe at novell.com (Guan Jun He) Date: Mon, 02 Nov 2009 01:45:04 -0700 Subject: [LLVMdev] strace for whole-program bitcodes In-Reply-To: <4AEAF6B3020000160000DDD7@novprvlin0050.provo.novell.com> References: <14ECB8FC41FFF347BB6B26A9E828C2BD303D7CBC58@GVW0432EXB.americas.hpqcorp.net> <7618fe50910150610n7a8972b3o83024d330c5fc734@mail.gmail.com> <84tyy0922c.fsf@sauna.l.org> <6a8523d60910150817x20b10e68l1434baad2e868b28@mail.gmail.com> <4AD7EAD2.2000008@mxc.ca> <4DF371AB7D17410093F44939C39AEE5A@andreic6e7fe55> <9430ad070910292011l1dbe827bn78d479702e85585a@mail.gmail.com> <4AEAF6B3020000160000DDD7@novprvlin0050.provo.novell.com> Message-ID: <4AEF0C90020000160000E3CE@novprvlin0050.provo.novell.com> any news?thanks >>> "Guan Jun He" 10/30/2009 2:22 PM >>> --emit-llvm, if not conflict >>> Paul Davey 10/30/2009 11:11 AM >>> --emit-llvm?? On Fri, Oct 30, 2009 at 7:55 AM, Viktor Kutuzov wrote: Hello everyone, I'm working on passing parameters for gold/LTO plug-in and could add this one as well. Just need an option name. Could anybody suggest one? Viktor ----- Original Message ----- From: "Nick Lewycky" To: "Daniel Dunbar" Cc: "Kelly, Terence P (HP Labs Researcher)" ; Sent: Thursday, October 15, 2009 8:38 PM Subject: Re: [LLVMdev] strace for whole-program bitcodes Daniel Dunbar wrote: > On Thu, Oct 15, 2009 at 7:14 AM, Timo Juhani Lindfors > wrote: >> Tianwei writes: >>> someone suggested me to use gold-plugin, I know nothing about it yet, I will >>> have a try later. Does anyone have a good solution for this problem? >> Afaik gold does not help here. I tried it and managed to only generate >> native code. > > "Just" gold isn't quite good enough, because at the last final link > steps gold will still generate native code. However, it should be > possible to find a way to get gold to leave the merged bitcode around > somewhere, or perhaps do something like llvm-ld. Nicholas? It's easy. In gold-plugin.cpp all_symbols_read_hook() where lto_codegen_compile(cg, ...) is currently called, call lto_codegen_write_merged_modules(cg, "/path/to/output.bc") instead. If someone were to rig this up to a command-line flag (search for LDPT_OPTION in the same file) then I would like to commit that change. Nick > The advantage of this approach is that it will potentially work with > build systems that call ar/ld directly. > >> I'm currently investigating an alternative approach to produce >> whole-program bitcodes: >> >> 1) add /tmp/wrap to PATH >> 2) create /tmp/wrap/gcc with the following contents >> >> #!/bin/sh >> exec llvm-gcc -specs /tmp/wrap/gcc.specs "$@" >> >> 3) llvm-gcc -dumpspecs > /tmp/wrap/gcc.specs >> 4) modify /tmp/wrap/gcc.specs so that it always passes -emit-llvm to cc1 >> 5) modify /tmp/wrap/gcc.specs so that it calls llvm-ld* instead of real >> ld and does not pass any unknown flags to it. >> >> With this approach I was able to compile and run airstrike (a 2d >> dogfighting game) in bitcode form very transparently with: >> >> $ make-bitcode fakeroot apt-get --build source airstrike >> $ sudo dpkg -i airstrike*.deb >> $ airstrike > > Very clever though. :) > > - Daniel > >> If you are interested I can try to rework my scripts to a shape where >> they could be used by somebody else. >> >> (*) I am not actually calling llvm-ld directly. Instead I have an >> "llvm-ld-exe" wrapper that calls llvm-ld and then uses "anytoexe" to >> pack the resulting bitcode to a shell script that can execute itself with >> lli and use the correct -load options. >> _______________________________________________ >> 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 -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091102/682aa890/attachment.html From ofv at wanadoo.es Mon Nov 2 04:28:03 2009 From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=) Date: Mon, 02 Nov 2009 11:28:03 +0100 Subject: [LLVMdev] llvm-mc build fails References: <91226b40911012257o5535f413o3094bb2cef34310b@mail.gmail.com> Message-ID: <87639t9q6k.fsf@telefonica.net> John Myers writes: > I'm looking for some pointers on how to troubleshoot this problem. I'm > trying to write a backend for the AVR. > There is an undefined reference at line 48 which is the line FrameInfo() is > on. I've tried to use the MSP430 and other targets as references so I'm not > sure > what changes I did would cause a problem on this line? cmake tracks library dependencies on $LLVM_ROOT/cmake/modules/LLVMLibDeps.txt That file is automatically updated on Unix and Unix-like platforms when all LLVM targets are included on the build. This means that either you update the file manually or run the build with MSYS passing -DLLVM_TARGETS_TO_BUILD=all on the cmake command line. The manual update would consist on adding this lines to the above mentioned file: set(MSVC_LIB_DEPS_LLVMAVRAsmPrinter LLVMAsmPrinter LLVMCodeGen LLVMCore LLVMMC LLVMAVRInfo LLVMSupport LLVMSystem LLVMTarget) set(MSVC_LIB_DEPS_LLVMAVRCodeGen LLVMCodeGen LLVMCore LLVMMC LLVMAVRInfo LLVMSelectionDAG LLVMSupport LLVMSystem LLVMTarget) set(MSVC_LIB_DEPS_LLVMAVRInfo LLVMSupport) which uses MSP430 as a template and supposses that your target is named `AVR' (case sensitive). In case you use the automatic update, the first run of the build will fail because the new dependencies are still not effective. Re-execute the build and it should work. -- ?scar From Juergen.Zimmermann at Sun.COM Mon Nov 2 07:00:04 2009 From: Juergen.Zimmermann at Sun.COM (Juergen Zimmermann - Sun Microsystems - Walldorf Germany) Date: Mon, 02 Nov 2009 14:00:04 +0100 Subject: [LLVMdev] llvm-gcc-4.2 RELEASE_26 bootstrap failure on Solaris/SPARC - unhandled REAL_TYPE during compilation of '__powitf2' In-Reply-To: References: <4AEAE189.6000900@Sun.COM> <4AEB05F0.3080506@Sun.COM> Message-ID: <4AEED7D4.7060504@Sun.COM> Anton, I went with the first alternative with some success. However, now I get some errors during the build of libgcc with 'multiply defined symbols'. One thing I noticed is the following fact: Definition in unwind-pe.h: static const unsigned char * read_sleb128 (const unsigned char *p, _Unwind_Sword *val) --- GCC 4.2.4 bootstrapped on Solaris/SPARC -bash-3.00$ nm unwind-dw2.o | grep read_sleb128 [9] | 1024| 84|FUNC |LOCL |0 |1 |read_sleb128 --- LLVM-gcc 4.2 on Solaris/SPARC with 64-bit long-double: -bash-3.00$ nm unwind-dw2.o | grep read_sleb128 [613] | 144| 0|FUNC |GLOB |0 |1 |read_sleb128 which means that LLVM generates this static function as global instead of local like the native GCC does. Any idea how this could be fixed? Regards, Juergen On 10/30/09 16:36, Anton Korobeynikov wrote: > Hello, Juergen > >> Ty->dump() prints "{double, double}" in the failing case (just before my >> introduced assert). > The answer is simple. The code in question contains extended IEEE FP > argument / return type (aka 'long double'). By default it's lowered > into struct {double, double} as you already saw and sparc currently > does not provide any argument layout hooks. > > There are two possible solutions for a moment: > 1. Temporary turn 128-bit fp into 64-bit fp (there should be some > define in config/sparc/*) > 2. Turn 128bit fp into normal first-class type (grep for TARGET_ZARCH > into llvm-types.cpp, where this mapping is done for s390x), but then > you will need to implement all codegen for 128-bit fp, since sparc > backend is currently really weak. > -- Sun Microsystems GmbH Juergen Zimmermann Altrottstrasse 31 ISV Engineering EMEA, Technical Lead for SAP 69190 Walldorf Phone: +49 (0)6227 356 256 Germany Fax: +49 (0)6227 356 222 mailto:Juergen.Zimmermann at Sun.COM Sun Microsystems GmbH Altrottstrasse 31, 69190 Walldorf Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Haering From anton at korobeynikov.info Mon Nov 2 07:09:27 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Mon, 2 Nov 2009 16:09:27 +0300 Subject: [LLVMdev] llvm-gcc-4.2 RELEASE_26 bootstrap failure on Solaris/SPARC - unhandled REAL_TYPE during compilation of '__powitf2' In-Reply-To: <4AEED7D4.7060504@Sun.COM> References: <4AEAE189.6000900@Sun.COM> <4AEB05F0.3080506@Sun.COM> <4AEED7D4.7060504@Sun.COM> Message-ID: Hello, Juergen > which means that LLVM generates this static function as global instead > of local like the native GCC does. > Any idea how this could be fixed? sparc asmprinter is old and was not maintained for years. Recently there was some huge asmprinter infrastructure refactoring in the LLVM. This might be just fallout from it. Or, the asmprinting is just incomplete. You might want to look there and, if possible, fix it (the best way will be migration to MCInst). -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From kuba at gcc.gnu.org Mon Nov 2 13:39:46 2009 From: kuba at gcc.gnu.org (Jakub Staszak) Date: Mon, 2 Nov 2009 16:39:46 -0300 Subject: [LLVMdev] PR3707 In-Reply-To: References:

Message-ID: <7F051257-06AA-4FAF-8F43-8302FA25F580@gcc.gnu.org> On Oct 12, 2009, at 2:27 AM, Chris Lattner wrote: > On Oct 10, 2009, at 7:48 AM, Jakub Staszak wrote: > >> This patch fixes pr3707. > > Can you explain a little more what this does? What is the intuition > behind disabling this optimization? Oh, this patch is crap :( Sorry for this. The problem is that we lack of optimization for case like: loopto: %timeout.0 = phi i32 [ 2000, %loopto ], [ %timeout.0.ph, %loopto.outer ] Then something like "%reg = MOV 2000" is inserted into loopto block and executed every time. I haven't found any optimization which can handle this and move instruction into some outer block. -- Jakub Staszak From kuba at gcc.gnu.org Mon Nov 2 13:40:24 2009 From: kuba at gcc.gnu.org (Jakub Staszak) Date: Mon, 2 Nov 2009 16:40:24 -0300 Subject: [LLVMdev] Non-local DSE optimization In-Reply-To: References: <830819AC-2A14-435D-86FE-CB09F73F31F6@gcc.gnu.org> <4A9F86F4.3070609@free.fr> <273A970E-E76D-4BC0-8EF0-64E9C391DA6F@gcc.gnu.org> <4AA36E3C.7070507@mxc.ca> Message-ID: Hello, I would like to remain my non-local dse patch. I made some small fixes for latest trunk. Can anyone look at this? -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: dse_ssu-3.patch Type: application/octet-stream Size: 17741 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091102/190f29aa/attachment.obj From dag at cray.com Mon Nov 2 13:48:17 2009 From: dag at cray.com (David Greene) Date: Mon, 2 Nov 2009 14:48:17 -0500 Subject: [LLVMdev] Moving AVX Upstream Message-ID: <200911021348.17474.dag@cray.com> Hey everyone, I'm at the point with our local AVX tree that I'm ready to move some stuff upstream. We've got most of the basic stuff implemented. The more esoteric stuff still has to be done. Because the more esoteric stuff might require some extensive changes to the existing AVX infrastructure, I suspect there might be quite a bit of church until we get things stabilized. Due to that, I'm proposing we create an "avx" branch so I can push changes upstream, get feedback, etc. without disturbing everyone else too much. I would make changes incrementally, substituting an AVX definition of existing SSE instructions and removing them from X86InstrSSE.td at the same time. That way we'll know when I've broken something. Then when it's ready we can move the whole bunch over at once. Does this sound reasonable, or do people prefer I merge to trunk? Merging to trunk will expose changes to more testing but could also cause a lot of pain for people. These are really EXTENSIVE changes to the x86 .td files and there could be more extensive changes in the future as I write some of the more complicated patterns. If a branch is preferable, can we get that created? Will commits to the branch go to the -commits list? It would be even better if -commits subject lines could be tagged with "[avx]" or something. What was the precedure for the use-diet branch? -Dave From lattner at apple.com Mon Nov 2 13:55:00 2009 From: lattner at apple.com (Tanya Lattner) Date: Mon, 2 Nov 2009 11:55:00 -0800 Subject: [LLVMdev] Moving AVX Upstream In-Reply-To: <200911021348.17474.dag@cray.com> References: <200911021348.17474.dag@cray.com> Message-ID: <49D0EC43-3C47-4322-A6C6-5F02CFC6DC2B@apple.com> On Nov 2, 2009, at 11:48 AM, David Greene wrote: > Hey everyone, > > I'm at the point with our local AVX tree that I'm ready to move some > stuff upstream. We've got most of the basic stuff implemented. The > more esoteric stuff still has to be done. > > Because the more esoteric stuff might require some extensive changes > to > the existing AVX infrastructure, I suspect there might be quite a bit > of church until we get things stabilized. > > Due to that, I'm proposing we create an "avx" branch so I can push > changes > upstream, get feedback, etc. without disturbing everyone else too > much. > I would make changes incrementally, substituting an AVX definition of > existing SSE instructions and removing them from X86InstrSSE.td at the > same time. That way we'll know when I've broken something. > > Then when it's ready we can move the whole bunch over at once. > > Does this sound reasonable, or do people prefer I merge to trunk? > Merging > to trunk will expose changes to more testing but could also cause a > lot of > pain for people. These are really EXTENSIVE changes to the x86 .td > files > and there could be more extensive changes in the future as I write > some of > the more complicated patterns. > You should do incremental development on trunk. If you create a branch, no one is going to look at those changes. > If a branch is preferable, can we get that created? Will commits to > the > branch go to the -commits list? It would be even better if -commits > subject lines could be tagged with "[avx]" or something. What was the > precedure for the use-diet branch? > Nope, it won't go to llvm-commits, it goes to a separate branch mailing list. -Tanya From dag at cray.com Mon Nov 2 14:51:41 2009 From: dag at cray.com (David Greene) Date: Mon, 2 Nov 2009 15:51:41 -0500 Subject: [LLVMdev] Moving AVX Upstream In-Reply-To: <49D0EC43-3C47-4322-A6C6-5F02CFC6DC2B@apple.com> References: <200911021348.17474.dag@cray.com> <49D0EC43-3C47-4322-A6C6-5F02CFC6DC2B@apple.com> Message-ID: <200911021451.41547.dag@cray.com> On Monday 02 November 2009 13:55, Tanya Lattner wrote: > You should do incremental development on trunk. If you create a > branch, no one is going to look at those changes. Ok. but I want to be very clear what that means. It means for each AVX instruction I rip out ALL of the existing SSE support for it. So when ADD gets implemented, ADD goes away from X86InstSSE.td. As things progress, we're almost certainly going to have to refactor or otherwise change things we've done in the past. That means extensive .td changes and some very large commits. If everyone's ok with this kind of churn on trunk, that's what I'll do. But SVN branches exist exactly for these kinds of disruptive changes. We used one for the use-diet so there's precedent. -Dave From clattner at apple.com Mon Nov 2 15:37:01 2009 From: clattner at apple.com (Chris Lattner) Date: Mon, 2 Nov 2009 13:37:01 -0800 Subject: [LLVMdev] Moving AVX Upstream In-Reply-To: <200911021451.41547.dag@cray.com> References: <200911021348.17474.dag@cray.com> <49D0EC43-3C47-4322-A6C6-5F02CFC6DC2B@apple.com> <200911021451.41547.dag@cray.com> Message-ID: <76BB2A37-5E97-417D-9409-C15499B12BC8@apple.com> On Nov 2, 2009, at 12:51 PM, David Greene wrote: > On Monday 02 November 2009 13:55, Tanya Lattner wrote: >> You should do incremental development on trunk. If you create a >> branch, no one is going to look at those changes. > > Ok. but I want to be very clear what that means. It means for each > AVX > instruction I rip out ALL of the existing SSE support for it. So when > ADD gets implemented, ADD goes away from X86InstSSE.td. > > As things progress, we're almost certainly going to have to refactor > or > otherwise change things we've done in the past. That means extensive > .td changes and some very large commits. Yep, that's the right thing to do. Just make sure that each patch is monotonic progress over the last one (doesn't introduce any known failures or bugs). Thanks David, -Chris From dag at cray.com Mon Nov 2 16:18:08 2009 From: dag at cray.com (David Greene) Date: Mon, 2 Nov 2009 17:18:08 -0500 Subject: [LLVMdev] Moving AVX Upstream In-Reply-To: <76BB2A37-5E97-417D-9409-C15499B12BC8@apple.com> References: <200911021348.17474.dag@cray.com> <200911021451.41547.dag@cray.com> <76BB2A37-5E97-417D-9409-C15499B12BC8@apple.com> Message-ID: <200911021618.08307.dag@cray.com> On Monday 02 November 2009 15:37, Chris Lattner wrote: > Yep, that's the right thing to do. Just make sure that each patch is > monotonic progress over the last one (doesn't introduce any known > failures or bugs). Thanks David, Ok. Cray is moving to St. Paul this week (yay!) so I'm not going to send anything until we're settled in next week. That way I'll see the feedback semi-immediately. -Dave From atomicdog.jwm at gmail.com Mon Nov 2 16:19:22 2009 From: atomicdog.jwm at gmail.com (John Myers) Date: Mon, 2 Nov 2009 14:19:22 -0800 Subject: [LLVMdev] llvm-mc build fails In-Reply-To: References: <91226b40911012257o5535f413o3094bb2cef34310b@mail.gmail.com> Message-ID: <91226b40911021419o7bae8858wcf8e7898bc1fab72@mail.gmail.com> Thanks Anton, that was the problem. I didn't know there was target specific dependencies in the CMake directory. --John On Sun, Nov 1, 2009 at 11:31 PM, Anton Korobeynikov wrote: > Hello, John > > > There is an undefined reference at line 48 which is the line FrameInfo() > is > > on. I've tried to use the MSP430 and other targets as references so I'm > not > > sure > > what changes I did would cause a problem on this line? > It doesn't seem you're linking libTarget in. Have you tried not to use > cmake-generated makefiles? As for the cmake - it tracked the explicit > list of dependencies somewhere, you might want to update it as well > (and different target-specific places in CMakeList.txt files). > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091102/be6cdcee/attachment.html From mclachlan at apple.com Mon Nov 2 17:30:31 2009 From: mclachlan at apple.com (Jon McLachlan) Date: Mon, 2 Nov 2009 15:30:31 -0800 Subject: [LLVMdev] array index type shuffling in GEPs Message-ID: <6598F919-1416-484C-8D29-6A8298C26CB2@apple.com> Hey folks, I am hoping that someone might be able to help me better understand this design decision: For a 64 bit target, index's into GEP's of arrays are zext up to 64 bit integers, even if the variable itself is an alloca of only i32. Similarly, on a 32 bit target, index's into GEP's are trunc'd down to 32 bits even if they ultimately reference an alloc'd variable of type i64. My guess is that in the latter, there is a 2^32 limit on the number of elements in an array for 32 bit systems. This doesn't make sense for the former, though, since we're casting up to 64 bits from the smaller 32. So, does anyone have any insight, comments, or thoughts on why we're zext up to 64 bit representation? Take Care, ~Jon From atomicdog.jwm at gmail.com Mon Nov 2 21:04:06 2009 From: atomicdog.jwm at gmail.com (John Myers) Date: Mon, 2 Nov 2009 19:04:06 -0800 Subject: [LLVMdev] llvm-mc build fails In-Reply-To: <87639t9q6k.fsf@telefonica.net> References: <91226b40911012257o5535f413o3094bb2cef34310b@mail.gmail.com> <87639t9q6k.fsf@telefonica.net> Message-ID: <91226b40911021904y16a223b8yc3914906f67eb13f@mail.gmail.com> Hi ?scar, Thanks for the explanation. I was able to use the automatic update method. FYI, for some reason the first run build completed without failure. --John On Mon, Nov 2, 2009 at 2:28 AM, ?scar Fuentes wrote: > The following message is a courtesy copy of an article > that has been posted to gmane.comp.compilers.llvm.devel as well. > > John Myers writes: > > > I'm looking for some pointers on how to troubleshoot this problem. I'm > > trying to write a backend for the AVR. > > There is an undefined reference at line 48 which is the line FrameInfo() > is > > on. I've tried to use the MSP430 and other targets as references so I'm > not > > sure > > what changes I did would cause a problem on this line? > > cmake tracks library dependencies on > $LLVM_ROOT/cmake/modules/LLVMLibDeps.txt > > That file is automatically updated on Unix and Unix-like platforms when > all LLVM targets are included on the build. This means that either you > update the file manually or run the build with MSYS passing > -DLLVM_TARGETS_TO_BUILD=all on the cmake command line. > > The manual update would consist on adding this lines to the above > mentioned file: > > set(MSVC_LIB_DEPS_LLVMAVRAsmPrinter LLVMAsmPrinter LLVMCodeGen LLVMCore > LLVMMC LLVMAVRInfo LLVMSupport LLVMSystem LLVMTarget) > set(MSVC_LIB_DEPS_LLVMAVRCodeGen LLVMCodeGen LLVMCore LLVMMC LLVMAVRInfo > LLVMSelectionDAG LLVMSupport LLVMSystem LLVMTarget) > set(MSVC_LIB_DEPS_LLVMAVRInfo LLVMSupport) > > which uses MSP430 as a template and supposses that your target is named > `AVR' (case sensitive). > > In case you use the automatic update, the first run of the build will > fail because the new dependencies are still not effective. Re-execute > the build and it should work. > > -- > ?scar > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091102/a3e8201f/attachment.html From gohman at apple.com Mon Nov 2 21:17:21 2009 From: gohman at apple.com (Dan Gohman) Date: Mon, 2 Nov 2009 19:17:21 -0800 Subject: [LLVMdev] array index type shuffling in GEPs In-Reply-To: <6598F919-1416-484C-8D29-6A8298C26CB2@apple.com> References: <6598F919-1416-484C-8D29-6A8298C26CB2@apple.com> Message-ID: On Nov 2, 2009, at 3:30 PM, Jon McLachlan wrote: > Hey folks, > > I am hoping that someone might be able to help me better understand > this design decision: For a 64 bit target, index's into GEP's of > arrays are zext up to 64 bit integers, even if the variable itself is > an alloca of only i32. Similarly, on a 32 bit target, index's into > GEP's are trunc'd down to 32 bits even if they ultimately reference an > alloc'd variable of type i64. > > My guess is that in the latter, there is a 2^32 limit on the number > of elements in an array for 32 bit systems. This doesn't make sense > for the former, though, since we're casting up to 64 bits from the > smaller 32. So, does anyone have any insight, comments, or thoughts > on why we're zext up to 64 bit representation? GEP uses sext, not zext (though a sext can be replaced by a zext in some cases by a crafty optimizer). GEP indices are normalized to be pointer-sized integers. This is done to aid optimization, as GEPs are ultimately lowered to pointer-sized integer arithmetic on most targets, and exposing the casts to the optimizer earlier rather than later gives it more flexibility to fold them or rearrange the surrounding code. Dan From gohman at apple.com Mon Nov 2 23:06:31 2009 From: gohman at apple.com (Dan Gohman) Date: Mon, 02 Nov 2009 21:06:31 -0800 Subject: [LLVMdev] Indirect goto Message-ID: <9D0B9783-C759-4423-8F84-9BC6F02C0DCC@apple.com> Hello, There's been a flurry of activity around indrect goto recently. For anyone interested, here's a document explaining the curent design: http://nondot.org/sabre/LLVMNotes/IndirectGoto.txt Dan From victor.zverovich at googlemail.com Tue Nov 3 05:09:45 2009 From: victor.zverovich at googlemail.com (Victor Zverovich) Date: Tue, 3 Nov 2009 11:09:45 +0000 Subject: [LLVMdev] DenseMap iterator constness fix Message-ID: Dear all, The first of the proposed patches (DenseMapIterator.patch) forbids implicit conversion of DenseMap::const_iterator to DenseMap::iterator which was possible because DenseMapIterator inherited (publicly) from DenseMapConstIterator. Conversion the other way around is now allowed as one may expect. The template DenseMapConstIterator is removed and the template parameter IsConst which specifies whether the iterator is constant is added to DenseMapIterator. Actually IsConst parameter is not necessary since the constness can be determined from KeyT but this is not relevant to the fix and can be addressed later. The second patch (DenseMapIterator-clang.patch) corrects clang's usage of DenseMap iterators. Best regards, Victor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091103/51699ffd/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: DenseMapIterator.patch Type: application/octet-stream Size: 13667 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091103/51699ffd/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: DenseMapIterator-clang.patch Type: application/octet-stream Size: 3322 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091103/51699ffd/attachment-0001.obj From rich at pennware.com Tue Nov 3 07:48:03 2009 From: rich at pennware.com (Richard Pennington) Date: Tue, 03 Nov 2009 07:48:03 -0600 Subject: [LLVMdev] Debug info Message-ID: <4AF03493.30706@pennware.com> Hi, I'm trying to use the new debug info and I seem to have broken something. The attached LLVM assembly is the result of compiling a simple main() function. If I generate x86 assembly language from this I get the attached assembly file. The debug info seems complete, except that the .Lfunc_begin symbol is referenced but not defined in the .s file. llvm-dis, llvm-as, and llc seem perfectly happy with this, but the assembler complains about the undefined symbol. Any clues? -Rich -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: main.o.ll Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091103/0f149e71/attachment-0002.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: main.o.s Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091103/0f149e71/attachment-0003.pl From jyasskin at google.com Tue Nov 3 10:15:00 2009 From: jyasskin at google.com (Jeffrey Yasskin) Date: Tue, 3 Nov 2009 08:15:00 -0800 Subject: [LLVMdev] DenseMap iterator constness fix In-Reply-To: References: Message-ID: +template +struct If { typedef True Result; }; + +template +struct If { typedef False Result; }; These should probably go into include/llvm/Support/type_traits.h. In C++0x, this is named "conditional" (section 20.6.7), so I think you should use the same name, despite the standard committee's bad taste. + DenseMapIterator(const DenseMapIterator& I) This looks like it will make it impossible to copy const_iterators. I guess it doesn't because the copy-constructor is auto-generated, but please comment that and add tests for it and for the non-const->const conversion to unittests/ADT/DenseMapTest.cpp. Otherwise, the patches just change iterator to const_iterator, which looks fine. On Tue, Nov 3, 2009 at 3:09 AM, Victor Zverovich wrote: > Dear all, > The first of the proposed patches (DenseMapIterator.patch) forbids implicit > conversion of DenseMap::const_iterator to DenseMap::iterator which was > possible because DenseMapIterator inherited (publicly) from > DenseMapConstIterator. Conversion the other way around is now allowed as one > may expect. > The template DenseMapConstIterator is?removed and the template > parameter?IsConst which specifies whether the iterator is constant is?added > to?DenseMapIterator. > Actually IsConst parameter is not necessary since the constness can be > determined from KeyT but this is not relevant to the fix and can be > addressed later. > The second patch (DenseMapIterator-clang.patch) corrects clang's usage of > DenseMap iterators. > Best regards, > Victor > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > From mclachlan at apple.com Tue Nov 3 10:57:15 2009 From: mclachlan at apple.com (Jon McLachlan) Date: Tue, 3 Nov 2009 08:57:15 -0800 Subject: [LLVMdev] array index type shuffling in GEPs In-Reply-To: References: <6598F919-1416-484C-8D29-6A8298C26CB2@apple.com> Message-ID: <46EC69F8-C3E2-475E-A00C-96726DD76C25@apple.com> Ahh, many thx for the insight - it makes perfect sense :) On Nov 2, 2009, at 7:17 PM, Dan Gohman wrote: > > On Nov 2, 2009, at 3:30 PM, Jon McLachlan wrote: > >> Hey folks, >> >> I am hoping that someone might be able to help me better understand >> this design decision: For a 64 bit target, index's into GEP's of >> arrays are zext up to 64 bit integers, even if the variable itself is >> an alloca of only i32. Similarly, on a 32 bit target, index's into >> GEP's are trunc'd down to 32 bits even if they ultimately reference >> an >> alloc'd variable of type i64. >> >> My guess is that in the latter, there is a 2^32 limit on the number >> of elements in an array for 32 bit systems. This doesn't make sense >> for the former, though, since we're casting up to 64 bits from the >> smaller 32. So, does anyone have any insight, comments, or thoughts >> on why we're zext up to 64 bit representation? > > GEP uses sext, not zext (though a sext can be replaced by a zext > in some cases by a crafty optimizer). > > GEP indices are normalized to be pointer-sized integers. This > is done to aid optimization, as GEPs are ultimately lowered to > pointer-sized integer arithmetic on most targets, and exposing > the casts to the optimizer earlier rather than later gives it more > flexibility to fold them or rearrange the surrounding code. > > Dan > From Matthieu.Moy at grenoble-inp.fr Tue Nov 3 12:15:07 2009 From: Matthieu.Moy at grenoble-inp.fr (Matthieu Moy) Date: Tue, 03 Nov 2009 19:15:07 +0100 Subject: [LLVMdev] Broken link on http://llvm.org/docs/ReleaseNotes.html#brokengcc Message-ID: Hi, The link "Broken versions of GCC and other tools" on http://llvm.org/docs/ReleaseNotes.html points to #brokengcc, where it should point to http://llvm.org/docs/GettingStarted.html#brokengcc I guess. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ From j.prasanth.j at gmail.com Tue Nov 3 13:42:10 2009 From: j.prasanth.j at gmail.com (Prasanth J) Date: Wed, 4 Nov 2009 01:12:10 +0530 Subject: [LLVMdev] Problem running lli on ARM Message-ID: Hi all, I am in the process of developing a installer utility for ARM target which can compile any source files to ARM native executable. This installer utility should be present on target itself (whether this is feasible or not?). For achieving this i compiled llvm with clang for target. I copied the binaries to target and when it tried to compile a sample c code i am getting the following error. *# ../bin/clang hello.c clang: warning: not using the clang compiler for the 'arm' architecture clang: error: unable to make temporary file: /tmp/cc: can't make unique filename: No such file or directory clang: error: unable to make temporary file: /tmp/cc: can't make unique filename: No such file or directory # * my target device doesnot hav /tmp and it doesnot have write permission for creating any directory on root "/". is there anyway to tell clang to create temporary files in some other location other than "/tmp" ? can anyone help me in resolving this issue? pls let me know in case if any more information is required. i also tried the following method. in this method i created the llvm bitcode in my host x86 machine and then copied it to target and from target if i try to run the bitcode using lli tool i am getting the following error. * * *# ../../llvm-2.6-arm/bin/lli nestedloop.bc lli: /home/prasanth/LLVM_ARM/llvm-**target/llvm-2.6/include/llvm/**ADT/ilist.h:197: typename bidirectional_iterator::reference llvm::ilist_iterator::**operator*() const [with NodeTy = llvm::RecyclerStruct]: Assertion `Traits::getNext(NodePtr) != 0 && "Dereferencing end()!"' failed. 0 lli 0x007702b4 Stack dump: 0. Program arguments: ../../llvm-2.6-arm/bin/lli nestedloop.bc 1. Running pass 'ARM Instruction Selection' on function '@main' Aborted # * * *pls let me know how can i resolve these two issues. the target details are target arch : arm target cpu : arm1136jf-s Thanks and Regards, Prasanth J -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091104/20cc0cc2/attachment.html From nnmahaja at umail.iu.edu Tue Nov 3 15:29:44 2009 From: nnmahaja at umail.iu.edu (Nilesh Mahajan) Date: Tue, 3 Nov 2009 16:29:44 -0500 Subject: [LLVMdev] LLVM + FORTRAN 95 Message-ID: Hi all, I want to compile FORTRAN 95 code with LLVM. More specifically, I would like to get an AST dump of the program I compile, statically analyze the AST, make modifcations to the AST and then feed it back to LLVM. Do you have any hints as to how I should proceed about doing this. I noticed that clang has an ast-dump option but don't know whether it supports FORTRAN 95. I am a LLVM newbie and I am trying to install it on Linux. I followed the setup instructions carefully but I am still facing the following error when trying to compile a simple hello.c: llvm-gcc: error trying to exec 'cc1': execvp: No such file or directory Can anybody help me here? Also I am not sure if I should post these kind of questions to a different mailing list. Thanks, Nilesh. From dag at cray.com Tue Nov 3 15:46:51 2009 From: dag at cray.com (David Greene) Date: Tue, 3 Nov 2009 16:46:51 -0500 Subject: [LLVMdev] LLVM + FORTRAN 95 In-Reply-To: References: Message-ID: <200911031546.51655.dag@cray.com> On Tuesday 03 November 2009 15:29, Nilesh Mahajan wrote: > Hi all, > > I want to compile FORTRAN 95 code with LLVM. More specifically, I > would like to get an AST dump of the program I compile, statically > analyze the AST, make modifcations to the AST and then feed it back to > LLVM. Do you have any hints as to how I should proceed about doing > this. I noticed that clang has an ast-dump option but don't know > whether it supports FORTRAN 95. Your best bet is to use llvm-gfortran. I don't know what you mean by "AST." Do you really want an AST or something else (LLVM IR, something higher-level, etc.)? LLVM doesn't understand ASTs directly. Longer term, it sure would be nice to have flang. :) -Dave From clattner at apple.com Tue Nov 3 15:50:12 2009 From: clattner at apple.com (Chris Lattner) Date: Tue, 3 Nov 2009 13:50:12 -0800 Subject: [LLVMdev] Broken link on http://llvm.org/docs/ReleaseNotes.html#brokengcc In-Reply-To: References: Message-ID: <7D0ECA96-B0BB-4EFE-B5CA-544D201B414D@apple.com> fixed, thanks. On Nov 3, 2009, at 10:15 AM, Matthieu Moy wrote: > Hi, > > The link "Broken versions of GCC and other tools" on > http://llvm.org/docs/ReleaseNotes.html points to #brokengcc, where it > should point to http://llvm.org/docs/GettingStarted.html#brokengcc I > guess. > > -- > Matthieu Moy > http://www-verimag.imag.fr/~moy/ > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From rengolin at systemcall.org Tue Nov 3 16:11:07 2009 From: rengolin at systemcall.org (Renato Golin) Date: Tue, 3 Nov 2009 22:11:07 +0000 Subject: [LLVMdev] LLVM + FORTRAN 95 In-Reply-To: <200911031546.51655.dag@cray.com> References: <200911031546.51655.dag@cray.com> Message-ID: 2009/11/3 David Greene : > Your best bet is to use llvm-gfortran. ?I don't know what you mean by > "AST." ?Do you really want an AST or something else (LLVM IR, something > higher-level, etc.)? ?LLVM doesn't understand ASTs directly. Probably for high-level optimisations, or just to see if the parser is good, as I do in my compiler. But AST is language/compiler specific, I also recommend you to transform everything to LLVM IR and do your stuff there. The LLVM IR is more high level and extremely more expressive (types and everything) than GCC IR, so you probably get everything you want from there. > Longer term, it sure would be nice to have flang. ?:) That supports HPF!! Yeah! cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From nnmahaja at umail.iu.edu Tue Nov 3 17:24:57 2009 From: nnmahaja at umail.iu.edu (Nilesh Mahajan) Date: Tue, 3 Nov 2009 18:24:57 -0500 Subject: [LLVMdev] LLVM + FORTRAN 95 In-Reply-To: References: <200911031546.51655.dag@cray.com> Message-ID: Hi David/Renato, By AST I mean Abstract Syntax Tree. We are writing an optimization pass for some FORTRAN95 + MPI code that requires us to analyze the AST. We thought of 2 ways of doing this: 1. Compile the code using Clang/llvm-gfortran, get the textual AST dump (somehow), analyze the AST dump using Ruby, modify it and then feed back the modified AST to LLVM. 2. Do the analysis as an LLVM module. >From your comments, I get the feeling that 2nd option is the better option. Thanks for your responses! Nilesh. P.S. Does anybody have an idea about the 'llvm-gcc: error trying to exec 'cc1': execvp: No such file or directory' error? On Tue, Nov 3, 2009 at 5:11 PM, Renato Golin wrote: > 2009/11/3 David Greene : >> Your best bet is to use llvm-gfortran. ?I don't know what you mean by >> "AST." ?Do you really want an AST or something else (LLVM IR, something >> higher-level, etc.)? ?LLVM doesn't understand ASTs directly. > > Probably for high-level optimisations, or just to see if the parser is > good, as I do in my compiler. > > But AST is language/compiler specific, I also recommend you to > transform everything to LLVM IR and do your stuff there. The LLVM IR > is more high level and extremely more expressive (types and > everything) than GCC IR, so you probably get everything you want from > there. > > >> Longer term, it sure would be nice to have flang. ?:) > > That supports HPF!! Yeah! > > cheers, > --renato > > Reclaim your digital rights, eliminate DRM, learn more at > http://www.defectivebydesign.org/what_is_drm > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From dag at cray.com Tue Nov 3 17:47:50 2009 From: dag at cray.com (David Greene) Date: Tue, 3 Nov 2009 18:47:50 -0500 Subject: [LLVMdev] Pat<> & tlbgen Message-ID: <200911031747.51062.dag@cray.com> Can someone explain the magic behind the Pat<> construct and tblgen. >From X86InstrSSE.td: def : Pat<(v4f32 (vector_shuffle VR128:$src, (undef), MOVDDUP_shuffle_mask)), (MOVLHPSrr VR128:$src, VR128:$src)>, Requires<[HasSSE1]>; Where's the code in tblgen to emit the matching code for this? I'm trying to extend it so that Pat<> can be used as a general subclass for AVX: class Base : Pat ...; multiclass foo { def A : Base; def B : Base; } The idea is to let the user write ALL of the patterns for a mnemonic in one place: defm MOVLH : foo<(v4f32 (vector_shuffle VR128:$src, (undef), MOVDDUP_shuffle_mask)), (MOVLHPSrr VR128:$src, VR128:$src), some.other.params.for.generic.patterns>; Note that MOVLHPSrr would be something else. It's not valid here because it's not declared yet. I have other features for handling that. :) But I'm having trouble hacking tblgen to make this work. I'm not getting variable resolution to work correctly. I just want to know how Pat<> works right now. I can post a testcase later. -Dave From dag at cray.com Tue Nov 3 17:49:45 2009 From: dag at cray.com (David Greene) Date: Tue, 3 Nov 2009 18:49:45 -0500 Subject: [LLVMdev] LLVM + FORTRAN 95 In-Reply-To: References: Message-ID: <200911031749.45243.dag@cray.com> On Tuesday 03 November 2009 17:24, Nilesh Mahajan wrote: = > By AST I mean Abstract Syntax Tree. We are writing an optimization > pass for some FORTRAN95 + MPI code that requires us to analyze the > AST. We thought of 2 ways of doing this: > 1. Compile the code using Clang/llvm-gfortran, get the textual AST > dump (somehow), analyze the AST dump using Ruby, modify it and then > feed back the modified AST to LLVM. > 2. Do the analysis as an LLVM module. > From your comments, I get the feeling that 2nd option is the better option. It's the only option right now unless you want to hack the output of gfortran and somehow feed it back into gfortran. You REALLY don't want to try that. This is why we need flang. -Dave From rengolin at systemcall.org Tue Nov 3 18:01:31 2009 From: rengolin at systemcall.org (Renato Golin) Date: Wed, 4 Nov 2009 00:01:31 +0000 Subject: [LLVMdev] LLVM + FORTRAN 95 In-Reply-To: References: <200911031546.51655.dag@cray.com> Message-ID: 2009/11/3 Nilesh Mahajan : > 2. Do the analysis as an LLVM module. > From your comments, I get the feeling that 2nd option is the better option. And your analysis can be applied to other languages as well, maybe even C/C++ using MPI bindings? That'd be a great addition to LLVM! ;) cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From jon at ffconsultancy.com Tue Nov 3 18:39:21 2009 From: jon at ffconsultancy.com (Jon Harrop) Date: Wed, 4 Nov 2009 00:39:21 +0000 Subject: [LLVMdev] LLVM + FORTRAN 95 In-Reply-To: References: Message-ID: <200911040039.21117.jon@ffconsultancy.com> On Tuesday 03 November 2009 23:24:57 Nilesh Mahajan wrote: > Hi David/Renato, > > By AST I mean Abstract Syntax Tree. We are writing an optimization > pass for some FORTRAN95 + MPI code that requires us to analyze the > AST. We thought of 2 ways of doing this: > > 1. Compile the code using Clang/llvm-gfortran, get the textual AST > dump (somehow), analyze the AST dump using Ruby, modify it and then > feed back the modified AST to LLVM. > > 2. Do the analysis as an LLVM module. > > From your comments, I get the feeling that 2nd option is the better > option. I was doing something similar last year and tried writing my own Fortran lexer/parser and reusing some of the existing ones. I found it so hard that I ended up rewriting the 800kLOC of Fortran code in a more modern language by hand. Basically, the Fortran-related open source tools are so poorly written and unreliable that they are not worth using. AFAIK, the llvm-gfortran compiler is just an LLVM backend on GCC's Fortran front-end. GCC is awful so I would not recommend trying to get anything sensical out of it. One project I did have limited success with was g95-xml, which is a hacked version of GCC's g95 compiler that can output the nearest thing Fortran has to an AST as XML: http://g95-xml.sourceforge.net/ The "First attempts" version that I used was a Perl programmer's idea of a parse tree though. ;-) For example: The edges between nodes in the AST are represented by those hexadecimal values (!). IIRC, after a lot of effort writing OCaml code to decipher that "XML", I discovered that it did not, in fact, contain all of the information from the source code and could not be used to perform the automated transformation that I wanted. So my advice is certainly to compile your Fortran into LLVM IR because that is a far more sane and malleable format. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e From zhu.heyu at gmail.com Wed Nov 4 02:01:50 2009 From: zhu.heyu at gmail.com (Heyu Zhu) Date: Wed, 4 Nov 2009 16:01:50 +0800 Subject: [LLVMdev] newbie qustion: how to generate machine code for target thumb? Message-ID: Hello everyone, I want to generate machine code for target thumb, so run with bit code test.bc llc -march thumb test.bc -filetype obj -o test.o It doesn't generate test.o but show a message: "target doesn't support generation of this file type!" What's wrong? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091104/f4a7cfde/attachment.html From victor.zverovich at googlemail.com Wed Nov 4 02:27:29 2009 From: victor.zverovich at googlemail.com (Victor Zverovich) Date: Wed, 4 Nov 2009 08:27:29 +0000 Subject: [LLVMdev] DenseMap iterator constness fix In-Reply-To: References: Message-ID: Hi Jeffrey, You are right that the generated copy constructor is used for const_iterator. I have added a comment clarifying this. Also I have added the tests you suggested and corrected the comparison operators. Please find attached the updated patches. Best regards, Victor 2009/11/3 Jeffrey Yasskin > +template > +struct If { typedef True Result; }; > + > +template > +struct If { typedef False Result; }; > > These should probably go into include/llvm/Support/type_traits.h. In > C++0x, this is named "conditional" (section 20.6.7), so I think you > should use the same name, despite the standard committee's bad taste. > > + DenseMapIterator(const DenseMapIterator + KeyInfoT, ValueInfoT, false>& I) > > This looks like it will make it impossible to copy const_iterators. I > guess it doesn't because the copy-constructor is auto-generated, but > please comment that and add tests for it and for the non-const->const > conversion to unittests/ADT/DenseMapTest.cpp. > > Otherwise, the patches just change iterator to const_iterator, which looks > fine. > > On Tue, Nov 3, 2009 at 3:09 AM, Victor Zverovich > wrote: > > Dear all, > > The first of the proposed patches (DenseMapIterator.patch) forbids > implicit > > conversion of DenseMap::const_iterator to DenseMap::iterator which was > > possible because DenseMapIterator inherited (publicly) from > > DenseMapConstIterator. Conversion the other way around is now allowed as > one > > may expect. > > The template DenseMapConstIterator is removed and the template > > parameter IsConst which specifies whether the iterator is constant > is added > > to DenseMapIterator. > > Actually IsConst parameter is not necessary since the constness can be > > determined from KeyT but this is not relevant to the fix and can be > > addressed later. > > The second patch (DenseMapIterator-clang.patch) corrects clang's usage of > > DenseMap iterators. > > Best regards, > > Victor > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091104/70d963e7/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: DenseMapIterator2.patch Type: text/x-patch Size: 15546 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091104/70d963e7/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: DenseMapIterator-clang2.patch Type: text/x-patch Size: 3292 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091104/70d963e7/attachment-0001.bin From jyasskin at google.com Wed Nov 4 02:55:07 2009 From: jyasskin at google.com (Jeffrey Yasskin) Date: Wed, 4 Nov 2009 00:55:07 -0800 Subject: [LLVMdev] DenseMap iterator constness fix In-Reply-To: References: Message-ID: + // Otherwise this is a copy constructor for const_iterator. Do you mean "for iterator"? Otherwise, looks good to me. If you can commit this, please do. Otherwise, someone else should as I'm not going to be around tomorrow. On Wed, Nov 4, 2009 at 12:27 AM, Victor Zverovich wrote: > Hi Jeffrey, > You are right that the generated copy constructor is used for > const_iterator. I have added a comment clarifying this. Also I have added > the tests you suggested and corrected the comparison operators.?Please find > attached the updated patches. > Best regards, > Victor > 2009/11/3 Jeffrey Yasskin >> >> +template >> +struct If { typedef True Result; }; >> + >> +template >> +struct If { typedef False Result; }; >> >> These should probably go into include/llvm/Support/type_traits.h. In >> C++0x, this is named "conditional" (section 20.6.7), so I think you >> should use the same name, despite the standard committee's bad taste. >> >> + ?DenseMapIterator(const DenseMapIterator> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?KeyInfoT, ValueInfoT, false>& >> I) >> >> This looks like it will make it impossible to copy const_iterators. I >> guess it doesn't because the copy-constructor is auto-generated, but >> please comment that and add tests for it and for the non-const->const >> conversion to unittests/ADT/DenseMapTest.cpp. >> >> Otherwise, the patches just change iterator to const_iterator, which looks >> fine. >> >> On Tue, Nov 3, 2009 at 3:09 AM, Victor Zverovich >> wrote: >> > Dear all, >> > The first of the proposed patches (DenseMapIterator.patch) forbids >> > implicit >> > conversion of DenseMap::const_iterator to DenseMap::iterator which was >> > possible because DenseMapIterator inherited (publicly) from >> > DenseMapConstIterator. Conversion the other way around is now allowed as >> > one >> > may expect. >> > The template DenseMapConstIterator is?removed and the template >> > parameter?IsConst which specifies whether the iterator is constant >> > is?added >> > to?DenseMapIterator. >> > Actually IsConst parameter is not necessary since the constness can be >> > determined from KeyT but this is not relevant to the fix and can be >> > addressed later. >> > The second patch (DenseMapIterator-clang.patch) corrects clang's usage >> > of >> > DenseMap iterators. >> > Best regards, >> > Victor >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >> > > > From wendling at apple.com Wed Nov 4 02:59:15 2009 From: wendling at apple.com (Bill Wendling) Date: Wed, 4 Nov 2009 00:59:15 -0800 Subject: [LLVMdev] LLVM + FORTRAN 95 In-Reply-To: References: <200911031546.51655.dag@cray.com> Message-ID: <74EC19A8-474F-425C-95B4-EC299958B049@apple.com> On Nov 3, 2009, at 2:11 PM, Renato Golin wrote: >> Longer term, it sure would be nice to have flang. :) > > That supports HPF!! Yeah! > You realize that LLVM doesn't have data dependence analysis, so supporting HPF (with any Fortran front-end) won't be out-of-the-box. :-) -bw From wendling at apple.com Wed Nov 4 03:01:56 2009 From: wendling at apple.com (Bill Wendling) Date: Wed, 4 Nov 2009 01:01:56 -0800 Subject: [LLVMdev] LLVM + FORTRAN 95 In-Reply-To: References: <200911031546.51655.dag@cray.com> Message-ID: <5AF40068-C47E-4005-B439-D66E81B726FF@apple.com> On Nov 3, 2009, at 3:24 PM, Nilesh Mahajan wrote: > > P.S. Does anybody have an idea about the 'llvm-gcc: error trying to > exec 'cc1': execvp: No such file or directory' error? > The llvm-gcc executable is a driver-driver for the compiler. It "execs" the cc1 program. It's apparently not finding it. My first guess is that it's not in the place it expects it to be. On my system (Mac OS X), here's what I get from the `find' command: ./libexec/gcc/i386-apple-darwin10.0.0/4.2.1/cc1 ./libexec/gcc/i386-apple-darwin9.2.2/4.2.1/cc1 ./libexec/gcc/i386-apple-darwin9.4.0/4.2.1/cc1 ./libexec/gcc/i386-apple-darwin9.5.0/4.2.1/cc1 ./libexec/gcc/i386-apple-darwin9.6.0/4.2.1/cc1 ./libexec/gcc/x86_64-apple-darwin10.0.0/4.2.1/cc1 -bw From hans at hanshq.net Wed Nov 4 03:51:23 2009 From: hans at hanshq.net (Hans Wennborg) Date: Wed, 04 Nov 2009 10:51:23 +0100 Subject: [LLVMdev] BasicAliasAnalysis: Null pointers do not alias with anything Message-ID: <4AF14E9B.9060209@hanshq.net> This is the first patch I've sent to this project. Please be gentle :) LLVM fails to remove the dead load in the following code when running $./llvm-as -o - test.ll | ./opt -O3 -o - | ./llvm-dis -o - %t = type { i32 } declare void @foo(i8*) define void @f(%t* noalias nocapture %stuff ) { %p = getelementptr inbounds %t* %stuff, i32 0, i32 0 %before = load i32* %p call void @foo(i8* null) %after = load i32* %p ; <--- This should be removed! %sum = add i32 %before, %after; store i32 %sum, i32* %p ret void } The reason is that it is unsure whether the null pointer which is passed in the call to @foo may alias with %t. Obviously, a null pointer doesn't alias with anything, because it's not legal to read or write through it (right?). The attached patch adds this check to BasicAliasAnalysis, and makes the dead load go away in my test. Does this seem reasonable, and is my patch doing it the right way? / Hans -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.patch Type: text/x-patch Size: 766 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091104/8298ee32/attachment.bin From rengolin at systemcall.org Wed Nov 4 03:53:38 2009 From: rengolin at systemcall.org (Renato Golin) Date: Wed, 4 Nov 2009 09:53:38 +0000 Subject: [LLVMdev] LLVM + FORTRAN 95 In-Reply-To: <74EC19A8-474F-425C-95B4-EC299958B049@apple.com> References: <200911031546.51655.dag@cray.com> <74EC19A8-474F-425C-95B4-EC299958B049@apple.com> Message-ID: 2009/11/4 Bill Wendling : > You realize that LLVM doesn't have data dependence analysis, so supporting > HPF (with any Fortran front-end) won't be out-of-the-box. :-) I was just pushing a bit further, there might be someone listening that would like to do it... ;) But it is my opinion that any software written today that does not contemplate intrinsic parallelism (any type, but preferable most types) is a waste of time. The era of one processing unit per box was abandoned decades ago and yet, we seem to keep thinking serially, even when programming for multiple processors... Though, that's a long discussion for a completely different mailing list... ;) cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From baldrick at free.fr Wed Nov 4 04:19:47 2009 From: baldrick at free.fr (Duncan Sands) Date: Wed, 04 Nov 2009 11:19:47 +0100 Subject: [LLVMdev] newbie qustion: how to generate machine code for target thumb? In-Reply-To: References: Message-ID: <4AF15543.1030103@free.fr> Hi Heyu Zhu, > I want to generate machine code for target thumb, so run > with bit code test.bc > > llc -march thumb test.bc -filetype obj -o test.o > > It doesn't generate test.o but show a message: > > "target doesn't support generation of this file type!" writing object code directly is not supported yet (though it is being worked on), so for the moment you should not use "-filetype obj". Without this option llc will generate assembler, which you will need to assemble using an appropriate assembler. Best wishes, Duncan. From victor.zverovich at googlemail.com Wed Nov 4 05:00:35 2009 From: victor.zverovich at googlemail.com (Victor Zverovich) Date: Wed, 4 Nov 2009 11:00:35 +0000 Subject: [LLVMdev] DenseMap iterator constness fix In-Reply-To: References: Message-ID: Good catch! I meant "for iterator" of course. Attached is a corrected patch together with an old patch for clang just to keep them together. Could someone commit these, please? Thanks, Victor 2009/11/4 Jeffrey Yasskin > + // Otherwise this is a copy constructor for const_iterator. > > Do you mean "for iterator"? > > Otherwise, looks good to me. If you can commit this, please do. > Otherwise, someone else should as I'm not going to be around tomorrow. > > On Wed, Nov 4, 2009 at 12:27 AM, Victor Zverovich > wrote: > > Hi Jeffrey, > > You are right that the generated copy constructor is used for > > const_iterator. I have added a comment clarifying this. Also I have added > > the tests you suggested and corrected the comparison operators. Please > find > > attached the updated patches. > > Best regards, > > Victor > > 2009/11/3 Jeffrey Yasskin > >> > >> +template > >> +struct If { typedef True Result; }; > >> + > >> +template > >> +struct If { typedef False Result; }; > >> > >> These should probably go into include/llvm/Support/type_traits.h. In > >> C++0x, this is named "conditional" (section 20.6.7), so I think you > >> should use the same name, despite the standard committee's bad taste. > >> > >> + DenseMapIterator(const DenseMapIterator >> + KeyInfoT, ValueInfoT, false>& > >> I) > >> > >> This looks like it will make it impossible to copy const_iterators. I > >> guess it doesn't because the copy-constructor is auto-generated, but > >> please comment that and add tests for it and for the non-const->const > >> conversion to unittests/ADT/DenseMapTest.cpp. > >> > >> Otherwise, the patches just change iterator to const_iterator, which > looks > >> fine. > >> > >> On Tue, Nov 3, 2009 at 3:09 AM, Victor Zverovich > >> wrote: > >> > Dear all, > >> > The first of the proposed patches (DenseMapIterator.patch) forbids > >> > implicit > >> > conversion of DenseMap::const_iterator to DenseMap::iterator which was > >> > possible because DenseMapIterator inherited (publicly) from > >> > DenseMapConstIterator. Conversion the other way around is now allowed > as > >> > one > >> > may expect. > >> > The template DenseMapConstIterator is removed and the template > >> > parameter IsConst which specifies whether the iterator is constant > >> > is added > >> > to DenseMapIterator. > >> > Actually IsConst parameter is not necessary since the constness can be > >> > determined from KeyT but this is not relevant to the fix and can be > >> > addressed later. > >> > The second patch (DenseMapIterator-clang.patch) corrects clang's usage > >> > of > >> > DenseMap iterators. > >> > Best regards, > >> > Victor > >> > _______________________________________________ > >> > LLVM Developers mailing list > >> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091104/f08e98c7/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: DenseMapIterator2.patch Type: text/x-patch Size: 15540 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091104/f08e98c7/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: DenseMapIterator-clang2.patch Type: text/x-patch Size: 3292 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091104/f08e98c7/attachment-0001.bin From astifter-llvm at gmx.at Wed Nov 4 08:20:51 2009 From: astifter-llvm at gmx.at (Andreas Neustifter) Date: Wed, 04 Nov 2009 15:20:51 +0100 Subject: [LLVMdev] Determine branch coverage information In-Reply-To: <26141617.post@talk.nabble.com> References: <26141617.post@talk.nabble.com> Message-ID: <4AF18DC3.9090703@gmx.at> Hi Ahmed! Adventure wrote: > Hello everybody, I am a beginner in LLVM and need to know how to use > LLVM to instrument a C program and execute this instrumented program > with different test cases to determine the branch coverage information > for each test case. Any suggestion or help is more than welcomed. Thanks > in advance. Ahmed Raafat. (In the following instructions you have to insert your own values for the <...> stuff.) To instrument the C Program you have to compile it into a single bytecode file, I do this by translating each C file to bytecode $> llvm-gcc -emit-llvm -c -o .bc and then link them all together $> llvm-ld -stats -time-passes -link-as-library -disable-opt *.bc -o .1.bc This gives you an unoptimised bytecode file which is preferable in this case since it retains a somewhat 1:1 relation to your code so you can figure out the results afterwards. Now its time to instrument the code, I do this by running $> opt -stats -time-passes -insert-optimal-edge-profiling .1.bc -o .2.bc and add the profiling runtime support $> llvm-ld -stats -time-passes -link-as-library -disable-opt /lib/libprofile_rt.bca .2.bc -o .3.bc You can then create a native executable by $> llc .3.bc .s $> gcc -g .s -o When you run this executable (with your parameters) it creates a file called llvmprof.out which contains an edge profiling of your code. With $> llvm-prof -print-all-code .1.bc you can dump a bytecode file which is annotated with the recorded profiling information. If you do several runs of your executable all runs are combined in the single llvmprof.out and the results are accumulated and you can check if every codepath was executed during your tests. There is a tool in /utils/profile.pl which takes a single bytecode file and parameters and does all the work of instrumenting, running and executing llvm-prof in one go, but its a little outdated, I attached a newer version, but I guess its easier to write a script that does exactly the steps you need. YMMV. Andi -------------- next part -------------- A non-text attachment was scrubbed... Name: profile.pl Type: application/x-perl Size: 2862 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091104/ea0970e9/attachment.bin From hans at hanshq.net Wed Nov 4 08:33:19 2009 From: hans at hanshq.net (Hans Wennborg) Date: Wed, 04 Nov 2009 15:33:19 +0100 Subject: [LLVMdev] DeadStoreElimination: do better without TargetData Message-ID: <4AF190AF.6070900@hanshq.net> The attached patch makes DeadStoreElimination able to remove stores in store-store dependencies when the operand types are equal, even if there is no TargetData available. / Hans -------------- next part -------------- A non-text attachment was scrubbed... Name: DeadStoreElimination.patch Type: text/x-patch Size: 812 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091104/2056b524/attachment.bin From hans at hanshq.net Wed Nov 4 08:43:18 2009 From: hans at hanshq.net (Hans Wennborg) Date: Wed, 04 Nov 2009 15:43:18 +0100 Subject: [LLVMdev] BasicAliasAnalysis: constant does not alias with noalias parameter Message-ID: <4AF19306.20803@hanshq.net> Here is another change I'd like to suggest to the BasicAliasAnalysis. LLVM fails to remove the dead store in the following code: %t = type { i32 } define void @f(%t* noalias nocapture %stuff ) { %p = getelementptr inbounds %t* %stuff, i32 0, i32 0 store i32 1, i32* %p; <-- This store is dead %x = load i32* inttoptr (i32 12345 to i32*) store i32 %x, i32* %p ret void } when run through ./llvm-as -o - test2.ll | ./opt -O3 -o - | ./llvm-dis -o - The problem is that the alias analysis is unsure about whether %p and 12345 may alias. But since %p is derived from %stuff, which has the noalias attribute, and 12345 is a constant and therefore cannot be derived from %stuff, they cannot alias. I'm attaching a patch which implements this. Please comment on whether this is sane, and if my code is the right way of doing it. / Hans -------------- next part -------------- A non-text attachment was scrubbed... Name: BasicAliasAnalysis.patch Type: text/x-patch Size: 1151 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091104/33e67b8a/attachment.bin From dberlin at dberlin.org Wed Nov 4 09:19:29 2009 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 4 Nov 2009 10:19:29 -0500 Subject: [LLVMdev] BasicAliasAnalysis: Null pointers do not alias with anything In-Reply-To: <4AF14E9B.9060209@hanshq.net> References: <4AF14E9B.9060209@hanshq.net> Message-ID: <4aca3dc20911040719sbf950fbp266ffa5a6488aecb@mail.gmail.com> On Wed, Nov 4, 2009 at 4:51 AM, Hans Wennborg wrote: > > > The reason is that it is unsure whether the null pointer which is passed in > the call to @foo may alias with %t. Obviously, a null pointer doesn't alias > with anything, because it's not legal to read or write through it (right?). I don't remember whether LLVM's language spec says anything different, but whether null may alias anything is generally platform dependent. On some platforms, null may actually point to things and be dereferenced legally. (This is often used to speculatively executive conditionals involving pointer-derefs) From hans at hanshq.net Wed Nov 4 09:21:34 2009 From: hans at hanshq.net (Hans Wennborg) Date: Wed, 04 Nov 2009 16:21:34 +0100 Subject: [LLVMdev] DeadStoreElimination: do better without TargetData In-Reply-To: <4AF190AF.6070900@hanshq.net> References: <4AF190AF.6070900@hanshq.net> Message-ID: <4AF19BFE.4040509@hanshq.net> Re-posting with better-looking code. Hans Wennborg wrote: > The attached patch makes DeadStoreElimination able to remove stores in > store-store dependencies when the operand types are equal, even if there > is no TargetData available. > > / Hans > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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: DeadStoreElimination2.patch Type: text/x-patch Size: 1303 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091104/51fa87bf/attachment.bin From victor.zverovich at googlemail.com Wed Nov 4 09:32:48 2009 From: victor.zverovich at googlemail.com (Victor Zverovich) Date: Wed, 4 Nov 2009 15:32:48 +0000 Subject: [LLVMdev] just-in-time debugging of assertion failures with MSVC Message-ID: Dear all, I am writing a compiler backend using LLVM with MSVC and have noticed that in LLVM version 2.6 it is no longer possible to use Just-In-Time Debugger at the point of assertion failure. The call stack is printed instead and the debugger stops at some strange location with the call stack like the following: > msvcr80d.dll!_NMSG_WRITE(int rterrnum=5111881) Line 198 C msvcr80d.dll!_close_nolock(int fh=7209065) Line 93 + 0x67 bytes C msvcr80d.dll!_close_nolock(int fh=5111881) Line 93 + 0x67 bytes C msvcr80d.dll!_close_nolock(int fh=7209065) Line 93 + 0x67 bytes C msvcr80d.dll!_close_nolock(int fh=6619238) Line 93 + 0x67 bytes C libmmd.dll!0069006e() [Frames below may be incorrect and/or missing, no symbols loaded for libmmd.dll] msvcr80d.dll!_close_nolock(int fh=7209065) Line 93 + 0x67 bytes C msvcr80d.dll!_close_nolock(int fh=6619238) Line 93 + 0x67 bytes C libmmd.dll!0069006e() msvcr80d.dll!_close_nolock(int fh=7209065) Line 93 + 0x67 bytes C msvcr80d.dll!_close_nolock(int fh=6619238) Line 93 + 0x67 bytes C libmmd.dll!0069006e() msvcr80d.dll!_close_nolock(int fh=7209065) Line 93 + 0x67 bytes C msvcr80d.dll!_close_nolock(int fh=6619238) Line 93 + 0x67 bytes C libmmd.dll!0069006e() msvcr80d.dll!_close_nolock(int fh=5111881) Line 93 + 0x67 bytes C msvcr80d.dll!_close_nolock(int fh=5111881) Line 93 + 0x67 bytes C msvcr80d.dll!_close_nolock(int fh=5111881) Line 93 + 0x67 bytes C msvcr80d.dll!_close_nolock(int fh=5177412) Line 93 + 0x67 bytes C Is there a way to get the old behaviour of handling (or indeed "not handling") the assertion failures? Best regards, Victor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091104/630a3a81/attachment.html From clattner at apple.com Wed Nov 4 10:32:40 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 4 Nov 2009 08:32:40 -0800 Subject: [LLVMdev] DeadStoreElimination: do better without TargetData In-Reply-To: <4AF19BFE.4040509@hanshq.net> References: <4AF190AF.6070900@hanshq.net> <4AF19BFE.4040509@hanshq.net> Message-ID: <01BA49E3-4D06-4CDF-BEE5-E8CC8C91E99D@apple.com> On Nov 4, 2009, at 7:21 AM, Hans Wennborg wrote: > Re-posting with better-looking code. Thanks, do you have a testcase showing what this does? -Chris > > Hans Wennborg wrote: >> The attached patch makes DeadStoreElimination able to remove stores >> in store-store dependencies when the operand types are equal, even >> if there is no TargetData available. >> / Hans >> ------------------------------------------------------------------------ >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > Index: lib/Transforms/Scalar/DeadStoreElimination.cpp > =================================================================== > --- lib/Transforms/Scalar/DeadStoreElimination.cpp (revision 86023) > +++ lib/Transforms/Scalar/DeadStoreElimination.cpp (working copy) > @@ -117,10 +117,12 @@ > > // If this is a store-store dependence, then the previous store > is dead so > // long as this store is at least as big as it. > - if (StoreInst *DepStore = dyn_cast(InstDep.getInst())) > - if (TD && > - TD->getTypeStoreSize(DepStore->getOperand(0)->getType()) <= > - TD->getTypeStoreSize(SI->getOperand(0)->getType())) { > + if (StoreInst *DepStore = dyn_cast(InstDep.getInst > ())) { > + const Type *DepType = DepStore->getOperand(0)->getType(); > + const Type *SIType = SI->getOperand(0)->getType(); > + if (DepType == SIType || > + (TD && > + TD->getTypeStoreSize(DepType) <= TD->getTypeStoreSize > (SIType))) { > // Delete the store and now-dead instructions that feed it. > DeleteDeadInstruction(DepStore); > NumFastStores++; > @@ -133,6 +135,7 @@ > --BBI; > continue; > } > + } > > // If we're storing the same value back to a pointer that we just > // loaded from, then the store can be removed. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From clattner at apple.com Wed Nov 4 10:33:54 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 4 Nov 2009 08:33:54 -0800 Subject: [LLVMdev] BasicAliasAnalysis: Null pointers do not alias with anything In-Reply-To: <4aca3dc20911040719sbf950fbp266ffa5a6488aecb@mail.gmail.com> References: <4AF14E9B.9060209@hanshq.net> <4aca3dc20911040719sbf950fbp266ffa5a6488aecb@mail.gmail.com> Message-ID: <8C21C61F-E2F1-45FE-9710-6E290F6A750C@apple.com> On Nov 4, 2009, at 7:19 AM, Daniel Berlin wrote: > On Wed, Nov 4, 2009 at 4:51 AM, Hans Wennborg wrote: > >> >> >> The reason is that it is unsure whether the null pointer which is >> passed in >> the call to @foo may alias with %t. Obviously, a null pointer >> doesn't alias >> with anything, because it's not legal to read or write through it >> (right?). > > I don't remember whether LLVM's language spec says anything different, > but whether null may alias anything is generally platform dependent. > > On some platforms, null may actually point to things and be > dereferenced legally. > > (This is often used to speculatively executive conditionals involving > pointer-derefs) Our current policy is to disallow dereferences of the null pointer, unless they are in the non-default address space. -Chris From hans at hanshq.net Wed Nov 4 12:13:30 2009 From: hans at hanshq.net (Hans Wennborg) Date: Wed, 04 Nov 2009 19:13:30 +0100 Subject: [LLVMdev] DeadStoreElimination: do better without TargetData In-Reply-To: <01BA49E3-4D06-4CDF-BEE5-E8CC8C91E99D@apple.com> References: <4AF190AF.6070900@hanshq.net> <4AF19BFE.4040509@hanshq.net> <01BA49E3-4D06-4CDF-BEE5-E8CC8C91E99D@apple.com> Message-ID: <4AF1C44A.1050801@hanshq.net> Sorry, I admit my e-mail was a bit unclear. Here is an example: declare void @foo() define void @f(i32* noalias %p) { store i32 1, i32* %p; <-- This is dead call void @foo() store i32 2, i32 *%p ret void } When run through ./llvm-as test.ll -o - | ./opt -O3 -S the dead store is not removed by the DSE pass. (The call to @foo is there to prevent InstCombine from folding the store instructions into one.) This is because DSE relies on TargetData to find out about pointer sizes. Apparently, there was some default value for this before, but when running with top of the tree today, it turned out that TD=NULL in the DSE code. We discussed this in the IRC channel, and someone pointed out that the more the pass can do without having info about the target, the better -- hence the patch. With the patch, DSE will at least see if the data types are equal, even though it doesn't have information about their sizes. This is enough for handling the example above, and probably many others as well. / Hans Chris Lattner wrote: > > On Nov 4, 2009, at 7:21 AM, Hans Wennborg wrote: > >> Re-posting with better-looking code. > > Thanks, do you have a testcase showing what this does? > > -Chris > >> >> Hans Wennborg wrote: >>> The attached patch makes DeadStoreElimination able to remove stores >>> in store-store dependencies when the operand types are equal, even if >>> there is no TargetData available. >>> / Hans >>> ------------------------------------------------------------------------ >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> Index: lib/Transforms/Scalar/DeadStoreElimination.cpp >> =================================================================== >> --- lib/Transforms/Scalar/DeadStoreElimination.cpp (revision 86023) >> +++ lib/Transforms/Scalar/DeadStoreElimination.cpp (working copy) >> @@ -117,10 +117,12 @@ >> >> // If this is a store-store dependence, then the previous store is >> dead so >> // long as this store is at least as big as it. >> - if (StoreInst *DepStore = dyn_cast(InstDep.getInst())) >> - if (TD && >> - TD->getTypeStoreSize(DepStore->getOperand(0)->getType()) <= >> - TD->getTypeStoreSize(SI->getOperand(0)->getType())) { >> + if (StoreInst *DepStore = dyn_cast(InstDep.getInst())) { >> + const Type *DepType = DepStore->getOperand(0)->getType(); >> + const Type *SIType = SI->getOperand(0)->getType(); >> + if (DepType == SIType || >> + (TD && >> + TD->getTypeStoreSize(DepType) <= >> TD->getTypeStoreSize(SIType))) { >> // Delete the store and now-dead instructions that feed it. >> DeleteDeadInstruction(DepStore); >> NumFastStores++; >> @@ -133,6 +135,7 @@ >> --BBI; >> continue; >> } >> + } >> >> // If we're storing the same value back to a pointer that we just >> // loaded from, then the store can be removed. >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From devang.patel at gmail.com Wed Nov 4 12:56:07 2009 From: devang.patel at gmail.com (Devang Patel) Date: Wed, 4 Nov 2009 10:56:07 -0800 Subject: [LLVMdev] Debug info In-Reply-To: <4AF03493.30706@pennware.com> References: <4AF03493.30706@pennware.com> Message-ID: <352a1fb20911041056r7d5b98cew5d91d738e8daf263@mail.gmail.com> Hi Richard, How do you produce this LLVM assembly? In newest form, llvm.dbg.func_start intrinsic is not used. - Devang On Tue, Nov 3, 2009 at 5:48 AM, Richard Pennington wrote: > Hi, > > I'm trying to use the new debug info and I seem to have broken something. > The attached LLVM assembly is the result of compiling a simple main() > function. If I generate x86 assembly language from this I get the attached > assembly file. > The debug info seems complete, except that the .Lfunc_begin symbol is > referenced but not defined in the .s file. > > llvm-dis, llvm-as, and llc seem perfectly happy with this, but the assembler > complains about the undefined symbol. Any clues? > > -Rich > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -- - Devang From rich at pennware.com Wed Nov 4 13:03:27 2009 From: rich at pennware.com (Richard Pennington) Date: Wed, 04 Nov 2009 13:03:27 -0600 Subject: [LLVMdev] Debug info In-Reply-To: <352a1fb20911041056r7d5b98cew5d91d738e8daf263@mail.gmail.com> References: <4AF03493.30706@pennware.com> <352a1fb20911041056r7d5b98cew5d91d738e8daf263@mail.gmail.com> Message-ID: <4AF1CFFF.2020800@pennware.com> Devang Patel wrote: > Hi Richard, > > How do you produce this LLVM assembly? In newest form, > llvm.dbg.func_start intrinsic is not used. > - > Devang > Hi Devang, The assembly is disassembled from bitcode that I create. I must be using obsolete remnants of the API. I'm calling EmitFunctionStart(), EmitStopPoint(), etc. What should I be using? -Rich From rich at pennware.com Wed Nov 4 13:13:28 2009 From: rich at pennware.com (Richard Pennington) Date: Wed, 04 Nov 2009 13:13:28 -0600 Subject: [LLVMdev] Debug info In-Reply-To: <4AF1CFFF.2020800@pennware.com> References: <4AF03493.30706@pennware.com> <352a1fb20911041056r7d5b98cew5d91d738e8daf263@mail.gmail.com> <4AF1CFFF.2020800@pennware.com> Message-ID: <4AF1D258.6070101@pennware.com> Richard Pennington wrote: > Devang Patel wrote: >> Hi Richard, >> >> How do you produce this LLVM assembly? In newest form, >> llvm.dbg.func_start intrinsic is not used. >> - >> Devang >> > Hi Devang, > > The assembly is disassembled from bitcode that I create. > > I must be using obsolete remnants of the API. I'm calling > EmitFunctionStart(), EmitStopPoint(), etc. What should I be using? > > -Rich I realize my question makes no sense. I was using code borrowed from clang. I'll check out what clang is doing now. -Rich From kennethuil at gmail.com Wed Nov 4 13:36:03 2009 From: kennethuil at gmail.com (Kenneth Uildriks) Date: Wed, 4 Nov 2009 13:36:03 -0600 Subject: [LLVMdev] DeadStoreElimination: do better without TargetData In-Reply-To: <4AF1C44A.1050801@hanshq.net> References: <4AF190AF.6070900@hanshq.net> <4AF19BFE.4040509@hanshq.net> <01BA49E3-4D06-4CDF-BEE5-E8CC8C91E99D@apple.com> <4AF1C44A.1050801@hanshq.net> Message-ID: <400d33ea0911041136j6cb8cd62l9e9e615f64eac46e@mail.gmail.com> On Wed, Nov 4, 2009 at 12:13 PM, Hans Wennborg wrote: > Sorry, I admit my e-mail was a bit unclear. > Here is an example: > > declare void @foo() > > define void @f(i32* noalias %p) { > ? ? ? ? store i32 1, i32* %p; <-- This is dead > ? ? ? ? call void @foo() > ? ? ? ? store i32 2, i32 *%p > ? ? ? ? ret void > } > > When run through ./llvm-as test.ll -o - | ./opt -O3 -S > the dead store is not removed by the DSE pass. > (The call to @foo is there to prevent InstCombine from folding the store > instructions into one.) > > This is because DSE relies on TargetData to find out about pointer > sizes. Apparently, there was some default value for this before, but > when running with top of the tree today, it turned out that TD=NULL in > the DSE code. Yes, there was a default value before - a single default value for all targets. On most targets, it was wrong, and led to the optimizer breaking code unless the module had the host's target data string packaged up inside of it. > > We discussed this in the IRC channel, and someone pointed out that the > more the pass can do without having info about the target, the better -- > ?hence the patch. My feeling exactly. > > With the patch, DSE will at least see if the data types are equal, even > though it doesn't have information about their sizes. This is enough for > handling the example above, and probably many others as well. Thanks. From regehr at cs.utah.edu Wed Nov 4 13:59:31 2009 From: regehr at cs.utah.edu (John Regehr) Date: Wed, 04 Nov 2009 11:59:31 -0800 Subject: [LLVMdev] idempotence Message-ID: <4AF1DD23.1010200@cs.utah.edu> The LLVM projects page says this: "We need some way to reason about errno. Consider a loop like this: for () x += sqrt(loopinvariant);" and: "The hard part of this project is figuring out how to describe errno in the optimizer" The important property here is the idempotence of sqrt(): it is potentially side-effecting, but that side effect is independent of the number of times it is called (with the same argument). Thus the solution to the errno problem seems to be an idempotence analysis pass, an idempotent function attribute, and a handful of passes (LICM, maybe more) that exploit this attribute. Putting on my volatile testing hat for a second, I feel compelled to mention that no function that potentially touches a volatile object is idempotent :). John Regehr From criswell at uiuc.edu Wed Nov 4 14:04:04 2009 From: criswell at uiuc.edu (John Criswell) Date: Wed, 4 Nov 2009 14:04:04 -0600 Subject: [LLVMdev] Debug Information for LLVM 2.6 and TOT Message-ID: <4AF1DE34.6020306@uiuc.edu> Dear All, 1) I recall reading somewhere that a few optimizations in LLVM 2.6 strip away debug information when such information interferes with optimization. Is this correct, and if so, does anyone know off-hand which optimizations do this? 2) I believe a new debug annotation design is being implemented in mainline LLVM for the 2.7 release. What is the current status of this work? Does it already yield more accurate debug information than LLVM 2.6? Thanks in advance for any answers. -- John T. From clattner at apple.com Wed Nov 4 17:13:23 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 4 Nov 2009 15:13:23 -0800 Subject: [LLVMdev] Pat<> & tlbgen In-Reply-To: <200911031747.51062.dag@cray.com> References: <200911031747.51062.dag@cray.com> Message-ID: <40046DD2-15BA-4C86-BD57-C327C2A273C1@apple.com> On Nov 3, 2009, at 3:47 PM, David Greene wrote: > Can someone explain the magic behind the Pat<> construct and tblgen. > >> From X86InstrSSE.td: > > def : Pat<(v4f32 (vector_shuffle VR128:$src, (undef), > MOVDDUP_shuffle_mask)), > (MOVLHPSrr VR128:$src, VR128:$src)>, Requires<[HasSSE1]>; > > Where's the code in tblgen to emit the matching code for this? I'm > trying to > extend it so that Pat<> can be used as a general subclass for AVX: Hi David, The secret here is that the 'pattern in instruction' syntax is just shorthand for a pat pattern, and tblgen internally converts all instructions into Pat pattern form. The only code to match patters handles the Pat syntax. > class Base : Pat ...; > > multiclass foo { > def A : Base; > def B : Base; > } I think this would just work if you end up with something like this: > multiclass foo { > def A : Pat; > def B : Pat; > } If the defs end up deriving from Pat, they should be automatically picked up by the existing code. -Chris From clattner at apple.com Wed Nov 4 17:21:20 2009 From: clattner at apple.com (Chris Lattner) Date: Wed, 4 Nov 2009 15:21:20 -0800 Subject: [LLVMdev] DeadStoreElimination: do better without TargetData In-Reply-To: <4AF1C44A.1050801@hanshq.net> References: <4AF190AF.6070900@hanshq.net> <4AF19BFE.4040509@hanshq.net> <01BA49E3-4D06-4CDF-BEE5-E8CC8C91E99D@apple.com> <4AF1C44A.1050801@hanshq.net> Message-ID: <02E2DF32-F0F1-4CA5-92C7-5414D3DF3D2B@apple.com> On Nov 4, 2009, at 10:13 AM, Hans Wennborg wrote: > Sorry, I admit my e-mail was a bit unclear. > Here is an example: > > declare void @foo() > > define void @f(i32* noalias %p) { > store i32 1, i32* %p; <-- This is dead > call void @foo() > store i32 2, i32 *%p > ret void > } > > When run through ./llvm-as test.ll -o - | ./opt -O3 -S > the dead store is not removed by the DSE pass. > (The call to @foo is there to prevent InstCombine from folding the > store instructions into one.) > > This is because DSE relies on TargetData to find out about pointer > sizes. Apparently, there was some default value for this before, but > when running with top of the tree today, it turned out that TD=NULL > in the DSE code. > > We discussed this in the IRC channel, and someone pointed out that > the more the pass can do without having info about the target, the > better -- hence the patch. > > With the patch, DSE will at least see if the data types are equal, > even though it doesn't have information about their sizes. This is > enough for handling the example above, and probably many others as > well. Thanks, applied here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091102/090396.html I'd appreciate it if you could resend your other patches in patch format like this, attached to the email with the testcase using filecheck. This commit should be a good example. Thanks for helping improve this area! -Chris From devang.patel at gmail.com Wed Nov 4 17:40:52 2009 From: devang.patel at gmail.com (Devang Patel) Date: Wed, 4 Nov 2009 15:40:52 -0800 Subject: [LLVMdev] Debug info In-Reply-To: <4AF1CFFF.2020800@pennware.com> References: <4AF03493.30706@pennware.com> <352a1fb20911041056r7d5b98cew5d91d738e8daf263@mail.gmail.com> <4AF1CFFF.2020800@pennware.com> Message-ID: <352a1fb20911041540s382b4f63o627a9f369be5665b@mail.gmail.com> Hi Richard, On Wed, Nov 4, 2009 at 11:03 AM, Richard Pennington wrote: > Devang Patel wrote: >> Hi Richard, >> >> How do you produce this LLVM assembly? In newest form, >> llvm.dbg.func_start intrinsic is not used. >> - >> Devang >> > Hi Devang, > > The assembly is disassembled from bitcode that I create. > > I must be using obsolete remnants of the API. I'm calling > EmitFunctionStart(), EmitStopPoint(), etc. What should I be using? Instead of calling EmitFunctionStart(), you keep track of lexical scopes in a stack. And instead of calling EmitStopPoint(), you update current location info and attach updated location info with subsequent instructions. See CGDebugInfo::EmitStopPoint() and CGDebugInfo::EmitFunctionStart() in CGDebugInfo.cpp from clang. http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?view=markup Here, - ATTACH_DEBUG_INFO_TO_AN_INSN is now defined. - IRBuilder is used to build IR. IRBuilder now provides APIs to keep track of current location info to encode debugging information. So whenever new instruction is created, the IRBuilder automatically attach current location info with the new instruction. Eventually, I'll document this and remove support for llvm.dbg.stoppoint and related intrinsics' support. - Devang From devang.patel at gmail.com Wed Nov 4 17:45:14 2009 From: devang.patel at gmail.com (Devang Patel) Date: Wed, 4 Nov 2009 15:45:14 -0800 Subject: [LLVMdev] Debug Information for LLVM 2.6 and TOT In-Reply-To: <4AF1DE34.6020306@uiuc.edu> References: <4AF1DE34.6020306@uiuc.edu> Message-ID: <352a1fb20911041545x16bf6292i65f84a6c13ded82e@mail.gmail.com> Hi John, On Wed, Nov 4, 2009 at 12:04 PM, John Criswell wrote: > Dear All, > > 1) I recall reading somewhere that a few optimizations in LLVM 2.6 strip > away debug information when such information interferes with > optimization. ?Is this correct, Yes. > and if so, does anyone know off-hand > which optimizations do this? The optimizer does not emit any statistics here. You can search various transformation passes' code to see whether they are handling DbgInfoIntrinsics or not. Or may be I misunderstood your question ? > 2) I believe a new debug annotation design is being implemented in > mainline LLVM for the 2.7 release. ?What is the current status of this > work? ?Does it already yield more accurate debug information than LLVM 2.6? It is still a work in progress. However, now it yields better scoping information when clang FE is used to generate debug info. - Devang From gohman at apple.com Wed Nov 4 18:54:23 2009 From: gohman at apple.com (Dan Gohman) Date: Wed, 4 Nov 2009 16:54:23 -0800 Subject: [LLVMdev] BasicAliasAnalysis: Null pointers do not alias with anything In-Reply-To: <4AF14E9B.9060209@hanshq.net> References: <4AF14E9B.9060209@hanshq.net> Message-ID: Hello, On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: > > > / Hans > Index: lib/Analysis/BasicAliasAnalysis.cpp > =================================================================== > --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) > +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) > @@ -633,6 +633,15 @@ > AliasAnalysis::AliasResult > BasicAliasAnalysis::aliasCheck(const Value *V1, unsigned V1Size, > const Value *V2, unsigned V2Size) { > + // Null pointers do not alias with anything > + if (const Constant *C = dyn_cast(V1)) > + if (C->isNullValue()) > + return NoAlias; > + > + if (const Constant *C = dyn_cast(V2)) > + if (C->isNullValue()) > + return NoAlias; > + As Chris mentioned, for consistency with what the rest of LLVM is doing, this should check whether the pointers are in the default address space (0). Also, this could be generalized by checking the results from getUnderlyingObject, since it's not valid to do arithmetic from null to reach an LLVM identified object either. Dan From gohman at apple.com Wed Nov 4 18:54:46 2009 From: gohman at apple.com (Dan Gohman) Date: Wed, 4 Nov 2009 16:54:46 -0800 Subject: [LLVMdev] BasicAliasAnalysis: constant does not alias with noalias parameter In-Reply-To: <4AF19306.20803@hanshq.net> References: <4AF19306.20803@hanshq.net> Message-ID: <4D39951A-5792-4BBC-9BEF-92540CE91349@apple.com> On Nov 4, 2009, at 6:43 AM, Hans Wennborg wrote: > Here is another change I'd like to suggest to the BasicAliasAnalysis. > > LLVM fails to remove the dead store in the following code: > > %t = type { i32 } > > define void @f(%t* noalias nocapture %stuff ) { > %p = getelementptr inbounds %t* %stuff, i32 0, i32 0 > > store i32 1, i32* %p; <-- This store is dead > > %x = load i32* inttoptr (i32 12345 to i32*) > store i32 %x, i32* %p > ret void > } > > > when run through > ./llvm-as -o - test2.ll | ./opt -O3 -o - | ./llvm-dis -o - > > > The problem is that the alias analysis is unsure about whether %p and 12345 may alias. But since %p is derived from %stuff, which has the noalias attribute, and 12345 is a constant and therefore cannot be derived from %stuff, they cannot alias. This sounds right. And actually, it's not limited to noalias; isIdentifiedObject objects don't alias inttoptr-casted integer literals either. I have a few comments on the patch below. > > I'm attaching a patch which implements this. Please comment on whether this is sane, and if my code is the right way of doing it. > > > / Hans > Index: lib/Analysis/BasicAliasAnalysis.cpp > =================================================================== > --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) > +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) > @@ -643,6 +643,23 @@ > if (!isa(V1->getType()) || !isa(V2->getType())) > return NoAlias; // Scalars cannot alias each other > > + // Constant ptr cannot alias with a noalias attribute > + if (isa(V1) && isa(V2->getType())) { > + while (const GEPOperator *g = dyn_cast(V2)) > + V2 = g->getOperand(0); > + > + if (const Argument *A = dyn_cast(V2)) > + if (A->hasNoAliasAttr()) > + return NoAlias; > + } else if (isa(V2) && isa(V1->getType())) { > + while (const GEPOperator *g = dyn_cast(V1)) > + V1 = g->getOperand(0); > + > + if (const Argument *A = dyn_cast(V1)) > + if (A->hasNoAliasAttr()) > + return NoAlias; > + } The GEP logic here is effectively doing (a subset of) what getUnderlyingObject does. It would be better to move these checks below the getUnderlyingObject calls just below so that they can use the results from those calls instead. And instead of checking for a no-alias argument, this code could use isIdentifiedObject instead, following my comment above. Dan > // Figure out what objects these things are pointing to if we can. > const Value *O1 = V1->getUnderlyingObject(); > const Value *O2 = V2->getUnderlyingObject(); > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From zhu.heyu at gmail.com Wed Nov 4 19:07:57 2009 From: zhu.heyu at gmail.com (Heyu Zhu) Date: Thu, 5 Nov 2009 09:07:57 +0800 Subject: [LLVMdev] newbie qustion: how to generate machine code for target thumb? In-Reply-To: <4AF15543.1030103@free.fr> References: <4AF15543.1030103@free.fr> Message-ID: Hi Duncan, Is it to say llvm-2.5 has no assembler and linker for target thumb and llvm-2.5 can only generate assembler file for the time being? Thanks 2009/11/4, Duncan Sands : > > Hi Heyu Zhu, > > I want to generate machine code for target thumb, so run >> with bit code test.bc >> llc -march thumb test.bc -filetype obj -o test.o >> It doesn't generate test.o but show a message: >> "target doesn't support generation of this file type!" >> > > writing object code directly is not supported yet (though it is being > worked > on), so for the moment you should not use "-filetype obj". Without this > option > llc will generate assembler, which you will need to assemble using an > appropriate assembler. > > Best wishes, > > Duncan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091105/dc5e18f9/attachment.html From pratnali at umail.iu.edu Thu Nov 5 01:51:48 2009 From: pratnali at umail.iu.edu (Pushkar Ratnalikar) Date: Thu, 5 Nov 2009 02:51:48 -0500 Subject: [LLVMdev] Clang and AST Generation Message-ID: <4ebaab310911042351s7304b88fuc089030aa7bf8e37@mail.gmail.com> Hello, I am trying to use Clang to generate AST for C code in a different format. This format is specific to the term rewriting system that we use for source-to-source transformations. Studying the ast generated by Clang using the "-ast-print" option to the clang-cc, I see that the pre-processor expands the code(expected). Is there a way to get around and not print all the information all the information and also keep the AST as close to the source as possible( avoiding constant folding). Thanks, Pushkar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091105/53ee97eb/attachment.html From baldrick at free.fr Thu Nov 5 02:01:41 2009 From: baldrick at free.fr (Duncan Sands) Date: Thu, 05 Nov 2009 09:01:41 +0100 Subject: [LLVMdev] newbie qustion: how to generate machine code for target thumb? In-Reply-To: References: <4AF15543.1030103@free.fr> Message-ID: <4AF28665.5030009@free.fr> Hi Heyu Zhu, > Is it to say llvm-2.5 has no assembler and linker for target thumb and > llvm-2.5 can only generate assembler file for the time being? that's right - you have to use the system assembler and linker. Best wishes, Duncan. From rjmccall at apple.com Thu Nov 5 02:22:14 2009 From: rjmccall at apple.com (John McCall) Date: Thu, 05 Nov 2009 00:22:14 -0800 Subject: [LLVMdev] Clang and AST Generation In-Reply-To: <4ebaab310911042351s7304b88fuc089030aa7bf8e37@mail.gmail.com> References: <4ebaab310911042351s7304b88fuc089030aa7bf8e37@mail.gmail.com> Message-ID: <4AF28B36.8060300@apple.com> Pushkar Ratnalikar wrote: > Hello, This is more appropriate for cfe-dev, not llvmdev. I'm forward this there; please follow-up only to that list. > I am trying to use Clang to generate AST for C code in a different > format. This format is specific to the term rewriting system that we > use for source-to-source transformations. > > Studying the ast generated by Clang using the "-ast-print" option to > the clang-cc, I see that the pre-processor expands the code(expected). > Is there a way to get around and not print all the information all the > information and also keep the AST as close to the source as possible( > avoiding constant folding). Could you clarify what you mean by not printing all the information? We have several different textual AST dumping mechanisms in various states of decay, but I didn't realize any of them did constant folding. John. From nicholas at mxc.ca Thu Nov 5 02:34:59 2009 From: nicholas at mxc.ca (Nick Lewycky) Date: Thu, 05 Nov 2009 00:34:59 -0800 Subject: [LLVMdev] BasicAliasAnalysis: Null pointers do not alias with anything In-Reply-To: References: <4AF14E9B.9060209@hanshq.net> Message-ID: <4AF28E33.8010700@mxc.ca> Dan Gohman wrote: > Hello, > > On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: >> >> / Hans >> Index: lib/Analysis/BasicAliasAnalysis.cpp >> =================================================================== >> --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) >> +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) >> @@ -633,6 +633,15 @@ >> AliasAnalysis::AliasResult >> BasicAliasAnalysis::aliasCheck(const Value *V1, unsigned V1Size, >> const Value *V2, unsigned V2Size) { >> + // Null pointers do not alias with anything >> + if (const Constant *C = dyn_cast(V1)) >> + if (C->isNullValue()) >> + return NoAlias; >> + >> + if (const Constant *C = dyn_cast(V2)) >> + if (C->isNullValue()) >> + return NoAlias; >> + > > As Chris mentioned, for consistency with what the rest of LLVM is doing, > this should check whether the pointers are in the default address space > (0). > > Also, this could be generalized by checking the results from > getUnderlyingObject, since it's not valid to do arithmetic from null to > reach an LLVM identified object either. Also, you can just test for "isa(V1)" directly instead of casting to Constant then asking isNullValue (assuming the types of V1 and V2 are going to be PointerTy which I believe they always will be, without looking at the code). Nick From nicholas at mxc.ca Thu Nov 5 02:44:36 2009 From: nicholas at mxc.ca (Nick Lewycky) Date: Thu, 05 Nov 2009 00:44:36 -0800 Subject: [LLVMdev] DeadStoreElimination: do better without TargetData In-Reply-To: <4AF1C44A.1050801@hanshq.net> References: <4AF190AF.6070900@hanshq.net> <4AF19BFE.4040509@hanshq.net> <01BA49E3-4D06-4CDF-BEE5-E8CC8C91E99D@apple.com> <4AF1C44A.1050801@hanshq.net> Message-ID: <4AF29074.8080107@mxc.ca> Hans Wennborg wrote: > Sorry, I admit my e-mail was a bit unclear. > Here is an example: > > declare void @foo() > > define void @f(i32* noalias %p) { > store i32 1, i32* %p; <-- This is dead > call void @foo() > store i32 2, i32 *%p > ret void > } Hold up. Is this correct? "noalias: This indicates that the pointer does not alias any global or any other parameter. The caller is responsible for ensuring that this is the case." - LangRef I've been interpreting this to mean that an arbitrary function may modify %p in this example, so long as it isn't *directly* held by a global or another argument. However, the global could contain a pointer to an object, indirectly pointing to %p. This would allow us to get more 'noalias' results from within @foo itself, but we not this optimization around it. I believe it's compatible with the definition of 'restrict' in C which noalias is modelled on. According to my interpretation, if the TD was the only issue blocking this transform then DSE was already buggy. Chris, could you please confirm your intention here? Nick From Arnaud.AllardDeGrandMaison at dibcom.com Thu Nov 5 02:41:33 2009 From: Arnaud.AllardDeGrandMaison at dibcom.com (Arnaud Allard de Grandmaison) Date: Thu, 5 Nov 2009 09:41:33 +0100 Subject: [LLVMdev] [cmake] : dotty handling Message-ID: <57C38DA176A0A34A9B9F3CCCE33D3C4A0104618D4689@FRPAR1CL009.coe.adi.dibcom.com> Hi, Here is a little patch to have cmake detect dotty, and if this was the case, update the HAVE_DOTTY and LLVM_PATH_DOTTY defines in include/llvm/Config/config.h. This should apply cleanly on TOT. Best regards, -- Arnaud de Grandmaison -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091105/edc399be/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-dotty.patch Type: application/octet-stream Size: 1260 bytes Desc: cmake-dotty.patch Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091105/edc399be/attachment.obj From oleg77 at gmail.com Thu Nov 5 04:30:49 2009 From: oleg77 at gmail.com (Oleg Knut) Date: Thu, 5 Nov 2009 12:30:49 +0200 Subject: [LLVMdev] create dummy function Message-ID: <278bcd900911050230m2fedefbcu1edc9739e0da0de6@mail.gmail.com> Hello, I have a simple question. How to create "dummy" function which will have no functionality behind (return nothing and do nothing)? Currently I'm trying to do this: llvm::Constant* c = Module.getOrInsertFunction("dummy", FunctionThatNeedsToBeReplaced.getFunctionType()); llvm::Function* dummy = llvm::cast(c); This way I create new function that do nothing.Then next step is: FunctionThatNeedsToBeReplaced.replaceAllUsesWith(dummy); This code is doing what I want to do, but it ends up with exception: ERROR: Program used external function 'dummy' which could not be resolved! I think I'm doing something wrong or there is a different way to create such functions. Thank you in advance, Oleg. From rengolin at systemcall.org Thu Nov 5 05:20:38 2009 From: rengolin at systemcall.org (Renato Golin) Date: Thu, 5 Nov 2009 11:20:38 +0000 Subject: [LLVMdev] create dummy function In-Reply-To: <278bcd900911050230m2fedefbcu1edc9739e0da0de6@mail.gmail.com> References: <278bcd900911050230m2fedefbcu1edc9739e0da0de6@mail.gmail.com> Message-ID: 2009/11/5 Oleg Knut : > Hello, > I have a simple question. How to create "dummy" function which will > have no functionality behind (return nothing and do nothing)? > Currently I'm trying to do this: > > llvm::Constant* c = Module.getOrInsertFunction("dummy", > FunctionThatNeedsToBeReplaced.getFunctionType()); > llvm::Function* dummy = llvm::cast(c); Hi Oleg, Every function needs a BasicBlock, even if the basic block just contains a return. The only reason to create a function without a basic block is when the function is extern'd and imported via JIT, but I guess it's not what you're attempting. Try this presentation and let me know if it's helpful: http://www.systemcall.org/rengolin/stuff/compiler/download/LLVM-pet-project.pdf cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From tianshuo_1 at 163.com Thu Nov 5 05:44:34 2009 From: tianshuo_1 at 163.com (tianshuo_1) Date: Thu, 5 Nov 2009 19:44:34 +0800 (CST) Subject: [LLVMdev] llvm-gcc-4.2-2.6 build failed, Message-ID: <26955286.540831257421474353.JavaMail.coremail@app179.163.com> I try to build llvm-gcc-4.2-2.6.source before build and install llvm-2.6, the configure is shown bellow ../llvm-gcc-4.2/configure --prefix=/home/ts/program/ --program-prefix=llvm- --enable-llvm=/home/ts/llvm/llvm-2.6 --enable-languages=c,c++ where, it is the path where llvm-2.6 source is stored, -enable-llvm=/home/ts/llvm/llvm-2.6 the "make" gave error message as bellow: ======================================================= In file included from ../../llvm-gcc-4.2/gcc/llvm-backend.cpp:23: ../../llvm-gcc-4.2/gcc/llvm-internal.h:40:35: error: llvm/System/DataTypes.h: No such file or directory ../../llvm-gcc-4.2/gcc/llvm-internal.h:44:41: error: llvm/Support/raw_os_ostream.h: No such file or directory ../../llvm-gcc-4.2/gcc/llvm-backend.cpp: In function ??void createPerFunctionOptimizationPasses()??: ../../llvm-gcc-4.2/gcc/llvm-backend.cpp:671: error: ??Less?? is not a member of ??llvm::CodeGenOpt?? ../../llvm-gcc-4.2/gcc/llvm-backend.cpp: In function ??void llvm_asm_file_end()??: ../../llvm-gcc-4.2/gcc/llvm-backend.cpp:874: error: ??getInt8PtrTy?? is not a member of ??llvm::Type?? ../../llvm-gcc-4.2/gcc/llvm-backend.cpp:893: error: ??getInt8PtrTy?? is not a member of ??llvm::Type?? ../../llvm-gcc-4.2/gcc/llvm-backend.cpp: In function ??void AddAnnotateAttrsToGlobal(llvm::GlobalValue*, tree_node*)??: ../../llvm-gcc-4.2/gcc/llvm-backend.cpp:1171: error: ??getInt8PtrTy?? is not a member of ??llvm::Type?? ../../llvm-gcc-4.2/gcc/llvm-backend.cpp: In function ??void make_decl_llvm(tree_node*)??: ../../llvm-gcc-4.2/gcc/llvm-backend.cpp:1635: error: ??const class llvm::Type?? has no member named ??isVoidTy?? make[3]: *** [llvm-backend.o] Error 1 make[3]: Leaving directory `/home/ts/llvm/llvm-gcc-4.2-obj/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/ts/llvm/llvm-gcc-4.2-obj' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/ts/llvm/llvm-gcc-4.2-obj' make: *** [all] Error 2 ============================================================ and , I found no file ,System/DataTypes.h, exist in the directory llvm-2.6/include/llvm/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091105/b0381b5d/attachment.html From anton at korobeynikov.info Thu Nov 5 06:19:36 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Thu, 5 Nov 2009 15:19:36 +0300 Subject: [LLVMdev] llvm-gcc-4.2-2.6 build failed, In-Reply-To: <26955286.540831257421474353.JavaMail.coremail@app179.163.com> References: <26955286.540831257421474353.JavaMail.coremail@app179.163.com> Message-ID: Hello > I try to build llvm-gcc-4.2-2.6.source before build and install llvm-2.6, > the configure is shown bellow > ../llvm-gcc-4.2/configure --prefix=/home/ts/program/ --program-prefix=llvm- > --enable-llvm=/home/ts/llvm/llvm-2.6 --enable-languages=c,c++ > where, it is the path where llvm-2.6 source is stored, > -enable-llvm=/home/ts/llvm/llvm-2.6 You need to build llvm itself first. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From baldrick at free.fr Thu Nov 5 06:48:50 2009 From: baldrick at free.fr (Duncan Sands) Date: Thu, 05 Nov 2009 13:48:50 +0100 Subject: [LLVMdev] llvm-gcc-4.2-2.6 build failed, In-Reply-To: <26955286.540831257421474353.JavaMail.coremail@app179.163.com> References: <26955286.540831257421474353.JavaMail.coremail@app179.163.com> Message-ID: <4AF2C9B2.9010100@free.fr> tianshuo_1 wrote: > I try to build llvm-gcc-4.2-2.6.source before build and install > llvm-2.6, the configure is shown bellow You need to build llvm first. --enable-llvm (and not -enable-llvm) should point to the directory in which you built llvm (this may be the same as the llvm source directory if you built llvm in place). Best wishes, Duncan. From oleg77 at gmail.com Thu Nov 5 07:10:40 2009 From: oleg77 at gmail.com (Oleg Knut) Date: Thu, 5 Nov 2009 15:10:40 +0200 Subject: [LLVMdev] create dummy function In-Reply-To: References: <278bcd900911050230m2fedefbcu1edc9739e0da0de6@mail.gmail.com> Message-ID: <278bcd900911050510n4584500eh269d4728a4907cf3@mail.gmail.com> Thank you very much for you help, Renato! I read through paper you referred and also this document - http://llvm.org/docs/tutorial/JITTutorial1.html Following these instructions to create successful function I run into some problems: 1) llvm::getGlobalContext() does not exists anymore? "llvm/LLVMContext.h" too? 2) creating instance of IRBuilder don't require template (from tutorial paper - IRBuilder<> builder(block)) So, I believe this is just outdated information? I think it just need some quick attention with getting materials up to date. In the end I got following code, that satisfy my needs: llvm::Constant* c = M.getOrInsertFunction(dummyFunctionName, F.getFunctionType()); llvm::Function* dummy = llvm::cast(c); dummy->setLinkage(llvm::Function::ExternalLinkage); dummy->setCallingConv(llvm::CallingConv::C); llvm::BasicBlock* block = llvm::BasicBlock::Create("entry", dummy); // no context needed llvm::IRBuilder builder(block); // no need in <> builder.CreateRetVoid(); Cheers, Oleg. 2009/11/5 Renato Golin : > 2009/11/5 Oleg Knut : >> Hello, >> I have a simple question. How to create "dummy" function which will >> have no functionality behind (return nothing and do nothing)? >> Currently I'm trying to do this: >> >> llvm::Constant* c = Module.getOrInsertFunction("dummy", >> FunctionThatNeedsToBeReplaced.getFunctionType()); >> llvm::Function* dummy = llvm::cast(c); > > Hi Oleg, > > Every function needs a BasicBlock, even if the basic block just > contains a return. > > The only reason to create a function without a basic block is when the > function is extern'd and imported via JIT, but I guess it's not what > you're attempting. > > Try this presentation and let me know if it's helpful: > > http://www.systemcall.org/rengolin/stuff/compiler/download/LLVM-pet-project.pdf > > cheers, > --renato > > Reclaim your digital rights, eliminate DRM, learn more at > http://www.defectivebydesign.org/what_is_drm > From rengolin at systemcall.org Thu Nov 5 07:17:17 2009 From: rengolin at systemcall.org (Renato Golin) Date: Thu, 5 Nov 2009 13:17:17 +0000 Subject: [LLVMdev] create dummy function In-Reply-To: <278bcd900911050510n4584500eh269d4728a4907cf3@mail.gmail.com> References: <278bcd900911050230m2fedefbcu1edc9739e0da0de6@mail.gmail.com> <278bcd900911050510n4584500eh269d4728a4907cf3@mail.gmail.com> Message-ID: 2009/11/5 Oleg Knut : > So, I believe this is just outdated information? I think it just need > some quick attention with getting materials up to date. Yup, outdated information. If you see the same example on the svn tree (examples/Kaleidoscope) the code is right and up-to-date. > In the end I got following code, that satisfy my needs: Return void an a dummy basic block, all you needed. ;) Glad to help. cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From stephan.reiter at gmail.com Thu Nov 5 07:32:01 2009 From: stephan.reiter at gmail.com (Stephan) Date: Thu, 5 Nov 2009 05:32:01 -0800 (PST) Subject: [LLVMdev] Functions: sret and readnone In-Reply-To: <5612891e-3fbf-4ff9-96da-56abc7d44086@o36g2000vbl.googlegroups.com> References: <135ebb010910050721t68118e75na082443e41c01d53@mail.gmail.com> <7A62B2C6-4FF3-4BF6-80F7-57ABB25BE0BA@apple.com> <5612891e-3fbf-4ff9-96da-56abc7d44086@o36g2000vbl.googlegroups.com> Message-ID: <1f6a2bb9-d009-4aaa-9a3c-b51c193e4d36@r24g2000yqd.googlegroups.com> It's been a while and I finally had the time to look into this. What I did was to build a custom AliasAnalysis pass, as Chris suggested, that returns AliasAnalysis::Mod for values passed to the sample function in the sret spot, and NoModRef for all other values. I'm also returning AliasAnalysis::AccessesArguments in the pass' getModRefBehavior methods. However, I haven't been successful with this approach and hope that someone has an idea on how to fix this. Here's a step by step illustration of the problem: 1. The following source code is compiled ... intrinsic float4 sample(int tex, float2 tc); float4 main(int tex, float2 tc) { float4 x = sample(tex, tc); return 0.0; } 2. ... into the following LLVM code (after a bunch of optimizations have run): define void @"main$int$float2"([4 x float]* noalias nocapture sret, i32, [2 x float]) nounwind { %5 = alloca [4 x float], align 4 ; <[4 x float]*> [#uses=1] call void @"sample$int$float2"([4 x float]* %5, i32 %1, [2 x float] %2) store [4 x float] zeroinitializer, [4 x float]* %0 ret void } declare void @"sample$int$float2"([4 x float]* noalias nocapture sret, i32, [2 x float]) nounwind As you can see, the call to the sample function is still present, although the actual value it is supposed to return via its sret parameter is never used. Using the AAEvalPass I found out that the alias analysis pass I implemented seems to work alright (it reports mod for %5): ===== Alias Analysis Evaluator Report ===== 3 Total Alias Queries Performed 3 no alias responses (100.0%) 0 may alias responses (0.0%) 0 must alias responses (0.0%) Alias Analysis Evaluator Pointer Alias Summary: 100%/0%/0% 3 Total ModRef Queries Performed 2 no mod/ref responses (66.6%) 1 mod responses (33.3%) 0 ref responses (0.0%) 0 mod & ref responses (0.0%) Alias Analysis Evaluator Mod/Ref Summary: 66%/33%/0%/0% Yet, DCE, DSE and GVN fail to remove the function call. (I'm not so sure which optimization pass to use, so I picked these three as they seemed to make sense.) Any ideas? Help would be very much appreciated! Thank you, Stephan On 6 Okt., 08:00, Stephan wrote: > On 5 Okt., 23:33, Dan Gohman wrote: > > > > > Is there a reason it needs to be an array? A vector of four floats > > wouldn't have this problem, if that's an option. > > Unfortunately that's not an option. At the moment I'm restricting > myself to the use of scalar code only, in order to be able to > vectorize the code easily later (e.g., float4 as it is now will then > become an array of four vectors for parallel processing of n (probably > 4, SSE) pixels). But thanks for coming up with this idea! > > Chris, I'll take a look at the AliasAnalysis functionality. Depending > on how much effort it is to implement a solution I might follow this > approach. If not, there's still Kenneth's new code generator to look > forward to. :) > > Thanks, > Stephan > _______________________________________________ > LLVM Developers mailing list > LLVM... at cs.uiuc.edu ? ? ? ?http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev From kavenchuk at gmail.com Thu Nov 5 07:39:02 2009 From: kavenchuk at gmail.com (Yaroslav Kavenchuk) Date: Thu, 05 Nov 2009 15:39:02 +0200 Subject: [LLVMdev] Strange error for libLLVMCore.a Message-ID: <4AF2D576.5050601@gmail.com> mingw, llvm 2.6 (buid with llvm-gcc) Example source code: http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html I change LLVMCreateJITCompiler(&engine, provider, &error); to LLVMCreateJITCompiler(&engine, provider, 3, &error); $ llvm-gcc `llvm-config --cflags` -c fac.c $ g++ `llvm-config --libs --cflags --ldflags core analysis executionengine jit interpreter native backend engine` fac.o -o fac fac.o: In function `main': c:\Work\llvm//fac.c:20: undefined reference to `LLVMModuleCreateWithName' c:\Work\llvm//fac.c:21: undefined reference to `LLVMInt32Type' c:\Work\llvm//fac.c:22: undefined reference to `LLVMInt32Type' c:\Work\llvm//fac.c:22: undefined reference to `LLVMFunctionType' c:\Work\llvm//fac.c:22: undefined reference to `LLVMAddFunction' c:\Work\llvm//fac.c:23: undefined reference to `LLVMSetFunctionCallConv' c:\Work\llvm//fac.c:24: undefined reference to `LLVMGetParam' c:\Work\llvm//fac.c:26: undefined reference to `LLVMAppendBasicBlock' c:\Work\llvm//fac.c:27: undefined reference to `LLVMAppendBasicBlock' c:\Work\llvm//fac.c:28: undefined reference to `LLVMAppendBasicBlock' c:\Work\llvm//fac.c:29: undefined reference to `LLVMAppendBasicBlock' c:\Work\llvm//fac.c:30: undefined reference to `LLVMCreateBuilder' c:\Work\llvm//fac.c:32: undefined reference to `LLVMPositionBuilderAtEnd' c:\Work\llvm//fac.c:33: undefined reference to `LLVMInt32Type' c:\Work\llvm//fac.c:33: undefined reference to `LLVMConstInt' c:\Work\llvm//fac.c:33: undefined reference to `LLVMBuildICmp' c:\Work\llvm//fac.c:34: undefined reference to `LLVMBuildCondBr' c:\Work\llvm//fac.c:36: undefined reference to `LLVMPositionBuilderAtEnd' c:\Work\llvm//fac.c:37: undefined reference to `LLVMInt32Type' c:\Work\llvm//fac.c:37: undefined reference to `LLVMConstInt' c:\Work\llvm//fac.c:38: undefined reference to `LLVMBuildBr' c:\Work\llvm//fac.c:40: undefined reference to `LLVMPositionBuilderAtEnd' c:\Work\llvm//fac.c:41: undefined reference to `LLVMInt32Type' c:\Work\llvm//fac.c:41: undefined reference to `LLVMConstInt' c:\Work\llvm//fac.c:41: undefined reference to `LLVMBuildSub' c:\Work\llvm//fac.c:43: undefined reference to `LLVMBuildCall' c:\Work\llvm//fac.c:44: undefined reference to `LLVMBuildMul' c:\Work\llvm//fac.c:45: undefined reference to `LLVMBuildBr' c:\Work\llvm//fac.c:47: undefined reference to `LLVMPositionBuilderAtEnd' c:\Work\llvm//fac.c:48: undefined reference to `LLVMInt32Type' c:\Work\llvm//fac.c:48: undefined reference to `LLVMBuildPhi' c:\Work\llvm//fac.c:51: undefined reference to `LLVMAddIncoming' c:\Work\llvm//fac.c:52: undefined reference to `LLVMBuildRet' c:\Work\llvm//fac.c:54: undefined reference to `LLVMVerifyModule' c:\Work\llvm//fac.c:55: undefined reference to `LLVMDisposeMessage' c:\Work\llvm//fac.c:59: undefined reference to `LLVMCreateModuleProviderForExistingModule' c:\Work\llvm//fac.c:61: undefined reference to `LLVMCreateJITCompiler' c:\Work\llvm//fac.c:64: undefined reference to `LLVMDisposeMessage' c:\Work\llvm//fac.c:68: undefined reference to `LLVMCreatePassManager' c:\Work\llvm//fac.c:69: undefined reference to `LLVMGetExecutionEngineTargetData' c:\Work\llvm//fac.c:69: undefined reference to `LLVMAddTargetData' c:\Work\llvm//fac.c:70: undefined reference to `LLVMAddConstantPropagationPass' c:\Work\llvm//fac.c:71: undefined reference to `LLVMAddInstructionCombiningPass' c:\Work\llvm//fac.c:72: undefined reference to `LLVMAddPromoteMemoryToRegisterPass' c:\Work\llvm//fac.c:74: undefined reference to `LLVMAddGVNPass' c:\Work\llvm//fac.c:75: undefined reference to `LLVMAddCFGSimplificationPass' c:\Work\llvm//fac.c:76: undefined reference to `LLVMRunPassManager' c:\Work\llvm//fac.c:77: undefined reference to `LLVMDumpModule' c:\Work\llvm//fac.c:79: undefined reference to `LLVMInt32Type' c:\Work\llvm//fac.c:79: undefined reference to `LLVMCreateGenericValueOfInt' c:\Work\llvm//fac.c:80: undefined reference to `LLVMRunFunction' c:\Work\llvm//fac.c:83: undefined reference to `LLVMGenericValueToInt' c:\Work\llvm//fac.c:85: undefined reference to `LLVMDisposePassManager' c:\Work\llvm//fac.c:86: undefined reference to `LLVMDisposeBuilder' c:\Work\llvm//fac.c:87: undefined reference to `LLVMDisposeExecutionEngine' collect2: ld returned 1 exit status $ llvm-config --libs --cflags --ldflags core analysis executionengine jit interpreter native backend engine -I/mingw/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fomit-frame-pointer -L/mingw/lib -lffi -lpsapi -limagehlp -lm -lLLVMX86AsmParser -lLLVMX86AsmPrinter -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86Info -lLLVMInterpreter -lLLVMJIT -lLLVMCodeGen -lLLVMScalarOpts -lLLVMTransformUtils -lLLVMipa -lLLVMExecutionEngine -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport -lLLVMSystem What is wrong? All undefined names from libLLVMCore.a -- WBR, Yaroslav Kavenchuk From criswell at uiuc.edu Thu Nov 5 10:43:11 2009 From: criswell at uiuc.edu (John Criswell) Date: Thu, 5 Nov 2009 10:43:11 -0600 Subject: [LLVMdev] Debug Information for LLVM 2.6 and TOT In-Reply-To: <352a1fb20911041545x16bf6292i65f84a6c13ded82e@mail.gmail.com> References: <4AF1DE34.6020306@uiuc.edu> <352a1fb20911041545x16bf6292i65f84a6c13ded82e@mail.gmail.com> Message-ID: <4AF3009F.9050708@uiuc.edu> Devang Patel wrote: > Hi John, > > On Wed, Nov 4, 2009 at 12:04 PM, John Criswell wrote: > >> Dear All, >> >> 1) I recall reading somewhere that a few optimizations in LLVM 2.6 strip >> away debug information when such information interferes with >> optimization. Is this correct, >> > > Yes. > > >> and if so, does anyone know off-hand >> which optimizations do this? >> > > The optimizer does not emit any statistics here. You can search > various transformation passes' code to see whether they are handling > DbgInfoIntrinsics or not. Or may be I misunderstood your question ? > Thanks for the information. You've understood me correctly. I was just hoping that somebody could save me the trouble of looking at all the optimizations to see which ones zap debug information. >> 2) I believe a new debug annotation design is being implemented in >> mainline LLVM for the 2.7 release. What is the current status of this >> work? Does it already yield more accurate debug information than LLVM 2.6? >> > > It is still a work in progress. However, now it yields better scoping > information when clang FE is used to generate debug info. > Does the debug facilities in LLVM TOT, at present, maintain information better than LLVM 2.6 (i.e., if a front-end puts the debug information in, will the optimizations not take it out)? Does the information that the llvm-gcc front-end adds comparable to what llvm-gcc in LLVM 2.6 does? The problem that I'm having is that the SAFECode debug tool uses LLVM debug information to print out nice error messages saying, "Your buffer overflow is at line in source file ." Before transforms started removing debug information, my tool would print out source line/file info that was acceptably accurate. After the change, it started printing out horribly wrong information (e.g., giving the source and line number of some inlined function called by the function that actually generated the memory error). I'm not so concerned with debug information being more accurate (although I like that, too). I'm more concerned with how well existing debug information is retained during optimizations. -- John T. > - > Devang > From clattner at apple.com Thu Nov 5 11:48:10 2009 From: clattner at apple.com (Chris Lattner) Date: Thu, 5 Nov 2009 09:48:10 -0800 Subject: [LLVMdev] DeadStoreElimination: do better without TargetData In-Reply-To: <4AF29074.8080107@mxc.ca> References: <4AF190AF.6070900@hanshq.net> <4AF19BFE.4040509@hanshq.net> <01BA49E3-4D06-4CDF-BEE5-E8CC8C91E99D@apple.com> <4AF1C44A.1050801@hanshq.net> <4AF29074.8080107@mxc.ca> Message-ID: <88E812A7-0A35-410F-9681-C2F570C1AEE2@apple.com> On Nov 5, 2009, at 12:44 AM, Nick Lewycky wrote: > > According to my interpretation, if the TD was the only issue > blocking this transform then DSE was already buggy. > > Chris, could you please confirm your intention here? I haven't thought about this, but this patch doesn't regress prior functionality it only makes it work when no TD is available. -Chris From devang.patel at gmail.com Thu Nov 5 12:12:49 2009 From: devang.patel at gmail.com (Devang Patel) Date: Thu, 5 Nov 2009 10:12:49 -0800 Subject: [LLVMdev] Debug Information for LLVM 2.6 and TOT In-Reply-To: <4AF3009F.9050708@uiuc.edu> References: <4AF1DE34.6020306@uiuc.edu> <352a1fb20911041545x16bf6292i65f84a6c13ded82e@mail.gmail.com> <4AF3009F.9050708@uiuc.edu> Message-ID: <352a1fb20911051012k53b22dcax4cef1bedf095a811@mail.gmail.com> Hi John, On Thu, Nov 5, 2009 at 8:43 AM, John Criswell wrote: > Does the debug facilities in LLVM TOT, at present, maintain information > better than LLVM 2.6 (i.e., if a front-end puts the debug information in, > will the optimizations not take it out)? ?Does the information that the > llvm-gcc front-end adds comparable to what llvm-gcc in LLVM 2.6 does? The FE has not changed significantly, other than bug fixes to improve debug info. > The problem that I'm having is that the SAFECode debug tool uses LLVM debug > information to print out nice error messages saying, "Your buffer overflow > is at line in source file ." ?Before transforms started removing > debug information, my tool would print out source line/file info that was > acceptably accurate. ?After the change, it started printing out horribly > wrong information (e.g., giving the source and line number of some inlined > function called by the function that actually generated the memory error). This is because, while cloning function body during inlining, the location information is also cloned, as expected. However, the inliner should update location information to indicate that this instruction is inlined at this location. I have local patch in my tree that is waiting finishing touch in codegen before I commit. I pasted it below for your reference. Now, each instruction can have location information attached with it. The location info (DILocation) include - unsigned - line number - unsigned - col number - DIScope - lexical scope - DILocation - inlined at location When an instruction is inlined, the first three fields will stay unchanged. But the inlined instruction will have non null "inlined at location" indicating where this instruction was inlined. - Devang Index: Utils/CloneFunction.cpp =================================================================== --- Utils/CloneFunction.cpp (revision 86036) +++ Utils/CloneFunction.cpp (working copy) @@ -20,6 +20,7 @@ #include "llvm/IntrinsicInst.h" #include "llvm/GlobalVariable.h" #include "llvm/Function.h" +#include "llvm/LLVMContext.h" #include "llvm/Support/CFG.h" #include "llvm/Transforms/Utils/ValueMapper.h" #include "llvm/Analysis/ConstantFolding.h" @@ -349,6 +350,27 @@ Ops.size(), Context, TD); } +static MDNode *UpdateInlinedAtInfo(MDNode *InsnMD, MDNode *TheCallMD, + LLVMContext &Context) { + DILocation ILoc(InsnMD); + if (ILoc.isNull()) return InsnMD; + + DILocation CallLoc(TheCallMD); + if (CallLoc.isNull()) return InsnMD; + + DILocation OrigLocation = ILoc.getOrigLocation(); + MDNode *NewLoc = TheCallMD; + if (!OrigLocation.isNull()) + NewLoc = UpdateInlinedAtInfo(OrigLocation.getNode(), TheCallMD, Context); + + SmallVector MDVs; + MDVs.push_back(InsnMD->getElement(0)); // Line + MDVs.push_back(InsnMD->getElement(1)); // Col + MDVs.push_back(InsnMD->getElement(2)); // Scope + MDVs.push_back(NewLoc); + return MDNode::get(Context, MDVs.data(), MDVs.size()); +} + /// CloneAndPruneFunctionInto - This works exactly like CloneFunctionInto, /// except that it does some simple constant prop and DCE on the fly. The /// effect of this is to copy significantly less code in cases where (for @@ -361,7 +383,8 @@ SmallVectorImpl &Returns, const char *NameSuffix, ClonedCodeInfo *CodeInfo, - const TargetData *TD) { + const TargetData *TD, + Instruction *TheCall) { assert(NameSuffix && "NameSuffix cannot be null!"); #ifndef NDEBUG @@ -411,8 +434,22 @@ } // Otherwise, remap the rest of the instructions normally. - for (; I != NewBB->end(); ++I) + unsigned DbgKind = 0; + MDNode *TheCallMD = NULL; + SmallVector MDVs; + LLVMContext &Context = OldFunc->getContext(); + if (TheCall && TheCall->hasMetadata()) { + DbgKind = Context.getMetadata().getMDKind("dbg"); + TheCallMD = Context.getMetadata().getMD(DbgKind, TheCall); + } + for (; I != NewBB->end(); ++I) { + if (TheCallMD && I->hasMetadata()) + if (MDNode *IMD = Context.getMetadata().getMD(DbgKind, I)) { + MDNode *NewMD = UpdateInlinedAtInfo(IMD, TheCallMD, Context); + Context.getMetadata().addMD(DbgKind, NewMD, I); + } RemapInstruction(I, ValueMap); + } } // Defer PHI resolution until rest of function is resolved, PHI resolution Index: Utils/InlineFunction.cpp =================================================================== --- Utils/InlineFunction.cpp (revision 86036) +++ Utils/InlineFunction.cpp (working copy) @@ -386,7 +386,7 @@ // (which can happen, e.g., because an argument was constant), but we'll be // happy with whatever the cloner can do. CloneAndPruneFunctionInto(Caller, CalledFunc, ValueMap, Returns, ".i", - &InlinedFunctionInfo, TD); + &InlinedFunctionInfo, TD, TheCall); // Remember the first block that is newly cloned over. FirstNewBlock = LastBlock; ++FirstNewBlock; From ofv at wanadoo.es Thu Nov 5 13:04:19 2009 From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=) Date: Thu, 05 Nov 2009 20:04:19 +0100 Subject: [LLVMdev] [cmake] : dotty handling References: <57C38DA176A0A34A9B9F3CCCE33D3C4A0104618D4689@FRPAR1CL009.coe.adi.dibcom.com> Message-ID: <87k4y494jw.fsf@telefonica.net> Arnaud Allard de Grandmaison writes: > Here is a little patch to have cmake detect dotty, and if this was the > case, update the HAVE_DOTTY and LLVM_PATH_DOTTY defines in > include/llvm/Config/config.h. > > This should apply cleanly on TOT. Applied. Thanks! -- ?scar From rich at pennware.com Thu Nov 5 13:39:05 2009 From: rich at pennware.com (Richard Pennington) Date: Thu, 05 Nov 2009 13:39:05 -0600 Subject: [LLVMdev] Debug Information for LLVM 2.6 and TOT In-Reply-To: <352a1fb20911051012k53b22dcax4cef1bedf095a811@mail.gmail.com> References: <4AF1DE34.6020306@uiuc.edu> <352a1fb20911041545x16bf6292i65f84a6c13ded82e@mail.gmail.com> <4AF3009F.9050708@uiuc.edu> <352a1fb20911051012k53b22dcax4cef1bedf095a811@mail.gmail.com> Message-ID: <4AF329D9.8030400@pennware.com> Devang Patel wrote: > This is because, while cloning function body during inlining, the > location information is also cloned, as expected. However, the inliner > should update location information to indicate that this instruction > is inlined at this location. I have local patch in my tree that is > waiting finishing touch in codegen before I commit. I pasted it below > for your reference. > > Now, each instruction can have location information attached with it. > The location info (DILocation) include > - unsigned - line number > - unsigned - col number > - DIScope - lexical scope > - DILocation - inlined at location > > When an instruction is inlined, the first three fields will stay > unchanged. But the inlined instruction will have non null "inlined at > location" indicating where this instruction was inlined. Devang, Could this approach be used for macros? I can single step through macro bodies, but I can't set a breakpoint at the point of the macro invocation. It sounds like this will allow it. http://ellcc.org/images/ssmacros.png -Rich From plmdvy at gmail.com Thu Nov 5 15:35:59 2009 From: plmdvy at gmail.com (Paul Davey) Date: Fri, 6 Nov 2009 10:35:59 +1300 Subject: [LLVMdev] Strange error for libLLVMCore.a In-Reply-To: <4AF2D576.5050601@gmail.com> References: <4AF2D576.5050601@gmail.com> Message-ID: <9430ad070911051335j64109365k7d6326740c375ae@mail.gmail.com> you want to use the execution engine and JIT but do not put them in the llvm-config line?? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091106/d26a0a02/attachment.html From kavenchuk at gmail.com Fri Nov 6 00:35:11 2009 From: kavenchuk at gmail.com (Yaroslav Kavenchuk) Date: Fri, 06 Nov 2009 08:35:11 +0200 Subject: [LLVMdev] Strange error for libLLVMCore.a In-Reply-To: <9430ad070911051335j64109365k7d6326740c375ae@mail.gmail.com> References: <4AF2D576.5050601@gmail.com> <9430ad070911051335j64109365k7d6326740c375ae@mail.gmail.com> Message-ID: <4AF3C39F.3080905@gmail.com> Paul Davey wrote: > you want to use the execution engine and JIT but do not put them in the > llvm-config line?? It's present: $ g++ `llvm-config --libs --cflags --ldflags core analysis executionengine jit interpreter native backend engine` fac.o -o fac Ok, I add `all` to llvm-config: $ llvm-gcc `llvm-config --cflags all` -c fac.c $ g++ `llvm-config --libs --cflags --ldflags all` fac.o -o fac fac.o:fake:(.text+0x1d): undefined reference to `LLVMModuleCreateWithName' fac.o:fake:(.text+0x25): undefined reference to `LLVMInt32Type' fac.o:fake:(.text+0x2d): undefined reference to `LLVMInt32Type' fac.o:fake:(.text+0x4c): undefined reference to `LLVMFunctionType' fac.o:fake:(.text+0x63): undefined reference to `LLVMAddFunction' ... -- WBR, Yaroslav Kavenchuk From baldrick at free.fr Fri Nov 6 05:12:49 2009 From: baldrick at free.fr (Duncan Sands) Date: Fri, 06 Nov 2009 12:12:49 +0100 Subject: [LLVMdev] Functions: sret and readnone In-Reply-To: <1f6a2bb9-d009-4aaa-9a3c-b51c193e4d36@r24g2000yqd.googlegroups.com> References: <135ebb010910050721t68118e75na082443e41c01d53@mail.gmail.com> <7A62B2C6-4FF3-4BF6-80F7-57ABB25BE0BA@apple.com> <5612891e-3fbf-4ff9-96da-56abc7d44086@o36g2000vbl.googlegroups.com> <1f6a2bb9-d009-4aaa-9a3c-b51c193e4d36@r24g2000yqd.googlegroups.com> Message-ID: <4AF404B1.2020506@free.fr> Hi Stephan, > intrinsic float4 sample(int tex, float2 tc); > > float4 main(int tex, float2 tc) > { > float4 x = sample(tex, tc); > return 0.0; > } without additional information it would be wrong to remove the call to sample because it might write to a global variable. > As you can see, the call to the sample function is still present, > although the actual value it is supposed to return via its sret > parameter is never used. Quite right too, see above. > Using the AAEvalPass I found out that the alias analysis pass I > implemented seems to work alright (it reports mod for %5): > > ===== Alias Analysis Evaluator Report ===== > 3 Total Alias Queries Performed > 3 no alias responses (100.0%) > 0 may alias responses (0.0%) > 0 must alias responses (0.0%) > Alias Analysis Evaluator Pointer Alias Summary: 100%/0%/0% > 3 Total ModRef Queries Performed > 2 no mod/ref responses (66.6%) > 1 mod responses (33.3%) > 0 ref responses (0.0%) > 0 mod & ref responses (0.0%) > Alias Analysis Evaluator Mod/Ref Summary: 66%/33%/0%/0% > > Yet, DCE, DSE and GVN fail to remove the function call. (I'm not so > sure which optimization pass to use, so I picked these three as they > seemed to make sense.) In order to perform this transform the optimizers would have to work out that sample does not modify any global state. This cannot be done without knowing the definition of sample, but you only provide a declaration. If you provided a body too then the GlobalsModRef analysis might be able to work it out. Ciao, Duncan. From tianshuo_1 at 163.com Fri Nov 6 05:41:29 2009 From: tianshuo_1 at 163.com (tianshuo_1) Date: Fri, 6 Nov 2009 19:41:29 +0800 (CST) Subject: [LLVMdev] llvm-gcc-4.2-2.6 build failed, In-Reply-To: <4AF2D07D.70408@free.fr> References: <4AF2D07D.70408@free.fr> <26955286.540831257421474353.JavaMail.coremail@app179.163.com>, <4AF2C9B2.9010100@free.fr> <200911052113161711730@163.com> Message-ID: <19972946.777131257507689109.JavaMail.coremail@bj163app46.163.com> Thank you for reply, I have tried building llvm-2.6 first in place, and configure llvm-gcc-4.2 with --enable-llvm=/path\to\llvm-2.6/, but, still the same problerm, and there's no files missed reported in the error message, such as "lvm/System/DataTypes.h", in the file system including /usr/include and ~/llvm/llvm-2.6/include/. May these files should be generated during llvm-2.6 building? I have compiled llvm-2.6 successfully and installed it in another directory, what's the reason for the problem? ??2009-11-05??"Duncan Sands" ?????? >Please do not reply to me personally: reply to the list. That way >others can comment, and the discussion is archived (which benefits >people who have the same problem at some later time). > >> ok, I have tried building llvm-2.6 first, in the same directory as >> source, and installed it in another directory.....but, the same problerm > >Did you change -enable-llvm to --enable-llvm? > >Best wishes, > >Duncan. ===================================================== try to build llvm-gcc-4.2-2.6.source before build and install llvm-2.6, the configure is shown bellow ../llvm-gcc-4.2/configure --prefix=/home/ts/program/ --program-prefix=llvm- --enable-llvm=/home/ts/llvm/llvm-2.6 --enable-languages=c,c++ where, it is the path where llvm-2.6 source is stored, -enable-llvm=/home/ts/llvm/llvm-2.6 the "make" gave error message as bellow: ======================================================= In file included from ../../llvm-gcc-4.2/gcc/llvm-backend.cpp:23: ../../llvm-gcc-4.2/gcc/llvm-internal.h:40:35: error: llvm/System/DataTypes.h: No such file or directory ../../llvm-gcc-4.2/gcc/llvm-internal.h:44:41: error: llvm/Support/raw_os_ostream.h: No such file or directory ../../llvm-gcc-4.2/gcc/llvm-backend.cpp: In function ??void createPerFunctionOptimizationPasses()??: ../../llvm-gcc-4.2/gcc/llvm-backend.cpp:671: error: ??Less?? is not a member of ??llvm::CodeGenOpt?? ../../llvm-gcc-4.2/gcc/llvm-backend.cpp: In function ??void llvm_asm_file_end()??: ../../llvm-gcc-4.2/gcc/llvm-backend.cpp:874: error: ??getInt8PtrTy?? is not a member of ??llvm::Type?? ../../llvm-gcc-4.2/gcc/llvm-backend.cpp:893: error: ??getInt8PtrTy?? is not a member of ??llvm::Type?? ../../llvm-gcc-4.2/gcc/llvm-backend.cpp: In function ??void AddAnnotateAttrsToGlobal(llvm::GlobalValue*, tree_node*)??: ../../llvm-gcc-4.2/gcc/llvm-backend.cpp:1171: error: ??getInt8PtrTy?? is not a member of ??llvm::Type?? ../../llvm-gcc-4.2/gcc/llvm-backend.cpp: In function ??void make_decl_llvm(tree_node*)??: ../../llvm-gcc-4.2/gcc/llvm-backend.cpp:1635: error: ??const class llvm::Type?? has no member named ??isVoidTy?? make[3]: *** [llvm-backend.o] Error 1 make[3]: Leaving directory `/home/ts/llvm/llvm-gcc-4.2-obj/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/ts/llvm/llvm-gcc-4.2-obj' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/ts/llvm/llvm-gcc-4.2-obj' make: *** [all] Error 2 ============================================================ and , I found no file ,System/DataTypes.h, exist in the directory llvm-2.6/include/llvm/ ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091106/505afadc/attachment.html From baldrick at free.fr Fri Nov 6 06:13:38 2009 From: baldrick at free.fr (Duncan Sands) Date: Fri, 06 Nov 2009 13:13:38 +0100 Subject: [LLVMdev] llvm-gcc-4.2-2.6 build failed, In-Reply-To: <19972946.777131257507689109.JavaMail.coremail@bj163app46.163.com> References: <4AF2D07D.70408@free.fr> <26955286.540831257421474353.JavaMail.coremail@app179.163.com>, <4AF2C9B2.9010100@free.fr> <200911052113161711730@163.com> <19972946.777131257507689109.JavaMail.coremail@bj163app46.163.com> Message-ID: <4AF412F2.4000009@free.fr> > and , I found no file ,System/DataTypes.h, exist in the directory llvm-2.6/include/llvm/ Are you sure you are building llvm-gcc-4.2-2.6 against llvm-2.6 and not against a version of llvm checked out from subversion? Ciao, Duncan. From stephan.reiter at gmail.com Fri Nov 6 06:19:20 2009 From: stephan.reiter at gmail.com (Stephan) Date: Fri, 6 Nov 2009 04:19:20 -0800 (PST) Subject: [LLVMdev] Functions: sret and readnone In-Reply-To: <4AF404B1.2020506@free.fr> References: <135ebb010910050721t68118e75na082443e41c01d53@mail.gmail.com> <7A62B2C6-4FF3-4BF6-80F7-57ABB25BE0BA@apple.com> <5612891e-3fbf-4ff9-96da-56abc7d44086@o36g2000vbl.googlegroups.com> <1f6a2bb9-d009-4aaa-9a3c-b51c193e4d36@r24g2000yqd.googlegroups.com> <4AF404B1.2020506@free.fr> Message-ID: <730d3f3e-31d7-48fd-909f-864bb7a96180@k4g2000yqb.googlegroups.com> Duncan, thanks for your answer! > In order to perform this transform the optimizers would have to work out > that sample does not modify any global state. ?This cannot be done without > knowing the definition of sample, but you only provide a declaration. Which is why I am trying to supply this additional information in a custom alias analysis pass, but it doesn't seem to work. (The AAEvalPass stats are precisely for this custom pass.) Could you take a look at the code, please? Am I missing something here? class VISIBILITY_HIDDEN MySretAliasAnalysis : public FunctionPass, public AliasAnalysis { std::map _srets; public: static char ID; MySretAliasAnalysis() : FunctionPass(&ID) { _srets["sample$int$float2"] = true; _srets["sample$int$float3"] = true; } void getAnalysisUsage(llvm::AnalysisUsage &usage) const { AliasAnalysis::getAnalysisUsage(usage); usage.setPreservesAll(); } bool runOnFunction(Function &F) { AliasAnalysis::InitializeAliasAnalysis(this); return false; } ModRefBehavior getModRefBehavior(CallSite CS, std::vector *Info = 0) { if(_srets.find(CS.getCalledFunction()->getName()) != _srets.end()) return AliasAnalysis::AccessesArguments; // only accesses args, no globals return AliasAnalysis::getModRefBehavior(CS, Info); } ModRefBehavior getModRefBehavior(Function *F, std::vector *Info = 0) { if(_srets.find(F->getName()) != _srets.end()) return AliasAnalysis::AccessesArguments; // only accesses args, no globals return AliasAnalysis::getModRefBehavior(F, Info); } ModRefResult getModRefInfo(CallSite CS, Value *P, unsigned Size) { std::string functionName = CS.getCalledFunction()->getNameStr(); if(_srets.find(functionName) != _srets.end()) { if(CS.hasArgument(P)) { if(CS.getArgument(0) == P) return AliasAnalysis::Mod; // modify value pointed to by sret param else return AliasAnalysis::NoModRef; // there aren't any other pointer args } } return AliasAnalysis::getModRefInfo(CS, P, Size); } bool hasNoModRefInfoForCalls() const { return false; } }; > If you provided a body too then the GlobalsModRef analysis might be able to > work it out. That's not an option because I want the sample function to be resolved as an external function by the jitter. Thanks for your time, Stephan From tianshuo_1 at 163.com Fri Nov 6 06:24:22 2009 From: tianshuo_1 at 163.com (tianshuo_1) Date: Fri, 6 Nov 2009 20:24:22 +0800 (CST) Subject: [LLVMdev] llvm-gcc-4.2-2.6 build failed, In-Reply-To: <4AF412F2.4000009@free.fr> References: <4AF412F2.4000009@free.fr> <4AF2D07D.70408@free.fr> <26955286.540831257421474353.JavaMail.coremail@app179.163.com>, <4AF2C9B2.9010100@free.fr> <200911052113161711730@163.com> <19972946.777131257507689109.JavaMail.coremail@bj163app46.163.com> Message-ID: <17800835.783551257510262211.JavaMail.coremail@bj163app67.163.com> oooo. I check out llvm form svn by "svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm", but not "svn co https://user at llvm.org/svn/llvm-project/llvm/trunk llvm",,,, ??2009-11-06??"Duncan Sands" ?????? >> and , I found no file ,System/DataTypes.h, exist in the directory llvm-2.6/include/llvm/ > >Are you sure you are building llvm-gcc-4.2-2.6 against llvm-2.6 and not against >a version of llvm checked out from subversion? > >Ciao, > >Duncan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091106/c0a91ca9/attachment.html From baldrick at free.fr Fri Nov 6 07:02:39 2009 From: baldrick at free.fr (Duncan Sands) Date: Fri, 06 Nov 2009 14:02:39 +0100 Subject: [LLVMdev] Functions: sret and readnone In-Reply-To: <730d3f3e-31d7-48fd-909f-864bb7a96180@k4g2000yqb.googlegroups.com> References: <135ebb010910050721t68118e75na082443e41c01d53@mail.gmail.com> <7A62B2C6-4FF3-4BF6-80F7-57ABB25BE0BA@apple.com> <5612891e-3fbf-4ff9-96da-56abc7d44086@o36g2000vbl.googlegroups.com> <1f6a2bb9-d009-4aaa-9a3c-b51c193e4d36@r24g2000yqd.googlegroups.com> <4AF404B1.2020506@free.fr> <730d3f3e-31d7-48fd-909f-864bb7a96180@k4g2000yqb.googlegroups.com> Message-ID: <4AF41E6F.9090004@free.fr> Hi Stephan, >> In order to perform this transform the optimizers would have to work out >> that sample does not modify any global state. This cannot be done without >> knowing the definition of sample, but you only provide a declaration. > > Which is why I am trying to supply this additional information in a > custom alias analysis pass, but it doesn't seem to work. (The > AAEvalPass stats are precisely for this custom pass.) > > Could you take a look at the code, please? Am I missing something > here? I think this cannot possibly work. Imagine that I am a pass trying to determine if the function call modifies global state. What would I have to do? I would have to consider all global variables, and query alias analysis to find out if any of them are modified. But how can I know all global variables? There is no way to know about global variables that are not declared in the module, so I can't query about those. And even if I could know about all global variables, checking all of them every time I want to consider deleting a function call would be very expensive and not worthwhile in general. GlobalsModRef only considers global variables with internal linkage IIRC (I may be wrong about this). That said, maybe there is some special AA query method that I don't know about that asks "do you write any global state". Ciao, Duncan. From stephan.reiter at gmail.com Fri Nov 6 07:22:36 2009 From: stephan.reiter at gmail.com (Stephan) Date: Fri, 6 Nov 2009 05:22:36 -0800 (PST) Subject: [LLVMdev] Functions: sret and readnone In-Reply-To: <4AF41E6F.9090004@free.fr> References: <135ebb010910050721t68118e75na082443e41c01d53@mail.gmail.com> <7A62B2C6-4FF3-4BF6-80F7-57ABB25BE0BA@apple.com> <5612891e-3fbf-4ff9-96da-56abc7d44086@o36g2000vbl.googlegroups.com> <1f6a2bb9-d009-4aaa-9a3c-b51c193e4d36@r24g2000yqd.googlegroups.com> <4AF404B1.2020506@free.fr> <730d3f3e-31d7-48fd-909f-864bb7a96180@k4g2000yqb.googlegroups.com> <4AF41E6F.9090004@free.fr> Message-ID: Hey Duncan, > That said, maybe there > is some special AA query method that I don't know about that asks "do you > write any global state". >From my limited understanding of the analysis framework, this method could be "getModRefBehavior". It returns a value of the ModRefBehavior enumeration type, which contains members such as DoesNotAccessMemory or OnlyReadsMemory. In my case AccessesArguments is the correct one, I guess. Directly from the header: // AccessesArguments - This function accesses function arguments in well // known (possibly volatile) ways, but does not access any other memory. So, there should be a way for optimization passes to know that the only memory such a function touches is memory, which is accessible via the pointers that are passed to it as arguments. In the particular case of my sample function: a pointer to a value on the stack. Best, Stephan From hans at hanshq.net Fri Nov 6 09:49:34 2009 From: hans at hanshq.net (Hans Wennborg) Date: Fri, 06 Nov 2009 16:49:34 +0100 Subject: [LLVMdev] BasicAliasAnalysis: Null pointers do not alias with anything In-Reply-To: References: <4AF14E9B.9060209@hanshq.net> Message-ID: <4AF4458E.1050504@hanshq.net> Dan Gohman wrote: > Hello, > > On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: >> >> / Hans >> Index: lib/Analysis/BasicAliasAnalysis.cpp >> =================================================================== >> --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) >> +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) >> @@ -633,6 +633,15 @@ >> AliasAnalysis::AliasResult >> BasicAliasAnalysis::aliasCheck(const Value *V1, unsigned V1Size, >> const Value *V2, unsigned V2Size) { >> + // Null pointers do not alias with anything >> + if (const Constant *C = dyn_cast(V1)) >> + if (C->isNullValue()) >> + return NoAlias; >> + >> + if (const Constant *C = dyn_cast(V2)) >> + if (C->isNullValue()) >> + return NoAlias; >> + > > As Chris mentioned, for consistency with what the rest of LLVM is doing, > this should check whether the pointers are in the default address space > (0). > > Also, this could be generalized by checking the results from > getUnderlyingObject, since it's not valid to do arithmetic from null to > reach an LLVM identified object either. I'm not sure what you mean by generalizing. Do you mean I should do the check on O1 and O2, which are the results of calls to getUnderlyingObject? Something like: if (const ConstantPointerNull *CPN = dyn_cast(O1)) if (CPN->getType()->getAddressSpace() == 0) return NoAlias; and the same for O2 (maybe extract it into a function?) / Hans > > Dan > From ofv at wanadoo.es Fri Nov 6 11:10:35 2009 From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=) Date: Fri, 06 Nov 2009 18:10:35 +0100 Subject: [LLVMdev] Any objections to removing 'win32/...' subtree from LLVM? References: <74c447500910251644o5207c1fcr4beb029ba1597488@mail.gmail.com> <74c447500910281935k49d4ed83p4a6b917adcb12fc@mail.gmail.com> Message-ID: <87eiob8tpw.fsf@telefonica.net> Chandler Carruth writes: > FYI, I'll plan on removing this subtree on Monday of next week if no > one else chimes in requesting a reprieve... The Visual C++ project files are still there. Anyone objected by private e-mail? Can we know the reasons just in case we can enhance the cmake build on accordance? In the past, the only reason for not removing win32/ was that the cmake-generated project files are not relocatable. As the win32/ project files seem out of date for months now, I reckon that the user who had that requirement switched to cmake. The mere existence of the win32/ subtree is a source of confussion for newcomers. Maybe the same applies to Xcode/ -- ?scar From clattner at apple.com Fri Nov 6 11:32:36 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 6 Nov 2009 09:32:36 -0800 Subject: [LLVMdev] DeadStoreElimination: do better without TargetData In-Reply-To: <4AF34AA9.8060003@hanshq.net> References: <4AF190AF.6070900@hanshq.net> <4AF19BFE.4040509@hanshq.net> <01BA49E3-4D06-4CDF-BEE5-E8CC8C91E99D@apple.com> <4AF1C44A.1050801@hanshq.net> <02E2DF32-F0F1-4CA5-92C7-5414D3DF3D2B@apple.com> <4AF34AA9.8060003@hanshq.net> Message-ID: On Nov 5, 2009, at 1:59 PM, Hans Wennborg wrote: > My apologies for not replying sooner; I've been away from keyboard all > day today. > >> Thanks, applied here: >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091102/090396.html >> >> >> I'd appreciate it if you could resend your other patches in patch >> format >> like this, attached to the email with the testcase using filecheck. >> This commit should be a good example. Thanks for helping improve >> this >> area! >> > > I'm not sure I follow you completely here. You want me to resend to > llvmdev, right -- not llvm-commits? Sure, either way works. > > What is the difference between the patch format i used and the one you > refer to, except for the testcase? > Is this filecheck thing documented somwhere? Specifically, please send it as an attachment instead of inline: http://llvm.org/docs/DeveloperPolicy.html#patches This makes it easier to apply. FileCheck is documented here: http://llvm.org/docs/TestingGuide.html#FileCheck Thanks! -Chris From kennethuil at gmail.com Fri Nov 6 13:22:50 2009 From: kennethuil at gmail.com (Kenneth Uildriks) Date: Fri, 6 Nov 2009 13:22:50 -0600 Subject: [LLVMdev] llvm.global_ctors Message-ID: <400d33ea0911061122o2de2d56ap5f938f6a182262da@mail.gmail.com> When you link two modules each of which contains a global_ctors array, is there a guarantee as to what order they'll run in? From anton at korobeynikov.info Fri Nov 6 14:03:13 2009 From: anton at korobeynikov.info (Anton Korobeynikov) Date: Fri, 6 Nov 2009 23:03:13 +0300 Subject: [LLVMdev] llvm.global_ctors In-Reply-To: <400d33ea0911061122o2de2d56ap5f938f6a182262da@mail.gmail.com> References: <400d33ea0911061122o2de2d56ap5f938f6a182262da@mail.gmail.com> Message-ID: Hello, Kenneth > When you link two modules each of which contains a global_ctors array, > is there a guarantee as to what order they'll run in? No, the order to static ctors is undefined. There is special "priority" attribute though. I don't remember whether we honor it or not... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University From peterke at gmail.com Fri Nov 6 14:28:05 2009 From: peterke at gmail.com (=?ISO-8859-1?Q?P=E9ter_Szil=E1gyi?=) Date: Fri, 6 Nov 2009 20:28:05 +0000 Subject: [LLVMdev] Sandboxing code Message-ID: <1d492d70911061228j1fc6d050v319812bbd2920017@mail.gmail.com> Hello, I'm absolutely 101% new to LLVM so please bare with me :). I'm trying to explore what LLVM can and cannot be used for. One thing I was wondering, whether it would be possible to execute an LLVM code in a completely sandboxed environment? By sandboxed I mean that the executed code should not have direct access to any system resources (i.e. hard drive, networking, devices), only through some specific API that I would provide. The idea is to be able to execute a random LLVM code from the internet in a completely safe way (provided that the specific code adheres to my libs in the first place... otherwise it shouldn't even compile). Thanks, Peter From criswell at uiuc.edu Fri Nov 6 14:48:30 2009 From: criswell at uiuc.edu (John Criswell) Date: Fri, 6 Nov 2009 14:48:30 -0600 Subject: [LLVMdev] Sandboxing code In-Reply-To: <1d492d70911061228j1fc6d050v319812bbd2920017@mail.gmail.com> References: <1d492d70911061228j1fc6d050v319812bbd2920017@mail.gmail.com> Message-ID: <4AF48B9E.70202@uiuc.edu> P?ter Szil?gyi wrote: > Hello, > > I'm absolutely 101% new to LLVM so please bare with me :). > > I'm trying to explore what LLVM can and cannot be used for. One > thing I was wondering, whether it would be possible to execute an LLVM > code in a completely sandboxed environment? By sandboxed I mean that > the executed code should not have direct access to any system > resources (i.e. hard drive, networking, devices), only through some > specific API that I would provide. The idea is to be able to execute a > random LLVM code from the internet in a completely safe way (provided > that the specific code adheres to my libs in the first place... > otherwise it shouldn't even compile). > The short answer is that you could build a system like this using LLVM, you could build it more quickly using the SAFECode compiler (which is built on LLVM and will be released as soon as we can get the legal paperwork done). However, you will need to add functionality to the LLVM/SAFECode system in order to be able to do the sandboxing. LLVM does not provide this functionality at present. The long answer: 1) You can build the program analysis and transformation passes needed to do this as a set of LLVM passes. 2) SAFECode provides control-flow integrity as one of its memory safety properties. It ensures that the return address of a function won't be overwritten, and it instruments indirect function calls with run-time checks to ensure that they call valid functions. 3) You could enhance the instrumentation on indirect function calls to ensure that they don't call system calls or other functions which you consider "dangerous." 4) You can combine this with operating system techniques (e.g., chroot jails, private name spaces (Linux/Plan 9 only), SELinux, etc.) to limit access to operating system resources. Depending on how you want to sandbox the code, using OS isolation techniques and/or virtual machines (e.g., VMWare, Xen) may be more straightforward and easier to implement. -- John T. > Thanks, > Peter > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From sumesh.uk at gmail.com Fri Nov 6 19:43:11 2009 From: sumesh.uk at gmail.com (Sumesh Udayakumaran) Date: Fri, 6 Nov 2009 17:43:11 -0800 Subject: [LLVMdev] MachineFunction::get Message-ID: <54a19460911061743g5ec8ce79o460c641eec992c62@mail.gmail.com> Hi I have a ModulePass in LLC that runs after most of codegen completes, right before OBJ emission. I want the ModulePass to iterate over all MachineFunctions, emulating them. I used to do this by iterating over all Module Function's, and using MachineFunction::get() to get the MachineFunction associated with said Function. In LLVM 2.6, MachineFunction::get() is gone. What is the new way of doing what I need? thanks Sumesh From gohman at apple.com Fri Nov 6 19:48:16 2009 From: gohman at apple.com (Dan Gohman) Date: Fri, 6 Nov 2009 17:48:16 -0800 Subject: [LLVMdev] BasicAliasAnalysis: Null pointers do not alias with anything In-Reply-To: <4AF4458E.1050504@hanshq.net> References: <4AF14E9B.9060209@hanshq.net> <4AF4458E.1050504@hanshq.net> Message-ID: <3CCEAD4B-9147-40FC-86F6-44B091204F4B@apple.com> On Nov 6, 2009, at 7:49 AM, Hans Wennborg wrote: > > I'm not sure what you mean by generalizing. > Do you mean I should do the check on O1 and O2, which are the results of calls to getUnderlyingObject? > > Something like: > > if (const ConstantPointerNull *CPN = dyn_cast(O1)) > if (CPN->getType()->getAddressSpace() == 0) > return NoAlias; > > and the same for O2 (maybe extract it into a function?) Yes, thanks. Dan From zhunansjtu at gmail.com Fri Nov 6 21:35:35 2009 From: zhunansjtu at gmail.com (Nan Zhu) Date: Sat, 7 Nov 2009 11:35:35 +0800 Subject: [LLVMdev] linking share libraries when building whole-program bitcode file Message-ID: Hi,all I'm working on how to build a whole-program bitcode file for big projects with a general solution,and I met a problem I simplify it as this: llvm-gcc -c -emit-llvm test.c llvm-ld test.o -lpthread //here llvm-ld tells me that "Cannot find library pthread" then I do this: llvm-ld test.o lli -load=/usr/lib/libpthread.so a.out.bc //lli tells me the /usr/lib/libpthread.so has a invalid ELF header What's the problem,my platform is Fedora 11 Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091107/e590e2a9/attachment.html From jyasskin at google.com Fri Nov 6 21:51:19 2009 From: jyasskin at google.com (Jeffrey Yasskin) Date: Fri, 6 Nov 2009 19:51:19 -0800 Subject: [LLVMdev] MachineFunction::get In-Reply-To: <54a19460911061743g5ec8ce79o460c641eec992c62@mail.gmail.com> References: <54a19460911061743g5ec8ce79o460c641eec992c62@mail.gmail.com> Message-ID: The proper incantation appears to be: MachineFunction &MF = getAnalysis().getMF(); I found that in lib/CodeGen/MachineFunctionPass.cpp. On the other hand, that means it probably doesn't exist in a ModulePass, since the MachineFunctionAnalysis is itself a FunctionPass, so any particular Function's MachineFunction will only exist while that function is being emitted. On Fri, Nov 6, 2009 at 5:43 PM, Sumesh Udayakumaran wrote: > Hi > I have a ModulePass in LLC that runs after most of codegen completes, > right before OBJ emission. ?I want the ModulePass to iterate over all > MachineFunctions, emulating them. ?I used to do this by iterating over > all Module Function's, and using MachineFunction::get() to get the > MachineFunction associated with said Function. > > In LLVM 2.6, MachineFunction::get() is gone. ?What is the ?new way ?of > doing what I need? > > thanks > Sumesh > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From clattner at apple.com Fri Nov 6 22:40:32 2009 From: clattner at apple.com (Chris Lattner) Date: Fri, 6 Nov 2009 20:40:32 -0800 Subject: [LLVMdev] interesting preso Message-ID: <911B2C1C-9E37-4985-A8F1-B115446A1A48@apple.com> I enjoyed this presentation: http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf Among other things it lists small code sequences when compiled with a small collection of compilers, including llvm 2.6. It looks like there are several fairly obvious things we could do better... -Chris From clattner at apple.com Sat Nov 7 02:32:20 2009 From: clattner at apple.com (Chris Lattner) Date: Sat, 7 Nov 2009 00:32:20 -0800 Subject: [LLVMdev] Any objections to removing 'win32/...' subtree from LLVM? In-Reply-To: <87eiob8tpw.fsf@telefonica.net> References: <74c447500910251644o5207c1fcr4beb029ba1597488@mail.gmail.com> <74c447500910281935k49d4ed83p4a6b917adcb12fc@mail.gmail.com> <87eiob8tpw.fsf@telefonica.net> Message-ID: On Nov 6, 2009, at 9:10 AM, ?scar Fuentes wrote: > Chandler Carruth writes: > >> FYI, I'll plan on removing this subtree on Monday of next week if no >> one else chimes in requesting a reprieve... > > The Visual C++ project files are still there. > > Anyone objected by private e-mail? Can we know the reasons just in > case > we can enhance the cmake build on accordance? In the past, the only > reason for not removing win32/ was that the cmake-generated project > files are not relocatable. As the win32/ project files seem out of > date > for months now, I reckon that the user who had that requirement > switched > to cmake. Removed in r86358. I don't know what happened to Chandler. -Chris From hans at hanshq.net Sat Nov 7 03:44:26 2009 From: hans at hanshq.net (Hans Wennborg) Date: Sat, 07 Nov 2009 10:44:26 +0100 Subject: [LLVMdev] BasicAliasAnalysis: Null pointers do not alias with anything In-Reply-To: <3CCEAD4B-9147-40FC-86F6-44B091204F4B@apple.com> References: <4AF14E9B.9060209@hanshq.net> <4AF4458E.1050504@hanshq.net> <3CCEAD4B-9147-40FC-86F6-44B091204F4B@apple.com> Message-ID: <4AF5417A.9030600@hanshq.net> Dan Gohman wrote: > On Nov 6, 2009, at 7:49 AM, Hans Wennborg wrote: >> I'm not sure what you mean by generalizing. >> Do you mean I should do the check on O1 and O2, which are the results of calls to getUnderlyingObject? >> >> Something like: >> >> if (const ConstantPointerNull *CPN = dyn_cast(O1)) >> if (CPN->getType()->getAddressSpace() == 0) >> return NoAlias; >> >> and the same for O2 (maybe extract it into a function?) > > Yes, thanks. Ok, patch with test case attached. / Hans > > Dan > -------------- next part -------------- A non-text attachment was scrubbed... Name: BasicAliasAnalysis.diff Type: text/x-patch Size: 1508 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091107/4b1e737b/attachment.bin From chandlerc at google.com Sat Nov 7 04:06:39 2009 From: chandlerc at google.com (Chandler Carruth) Date: Sat, 7 Nov 2009 02:06:39 -0800 Subject: [LLVMdev] Any objections to removing 'win32/...' subtree from LLVM? In-Reply-To: References: <74c447500910251644o5207c1fcr4beb029ba1597488@mail.gmail.com> <74c447500910281935k49d4ed83p4a6b917adcb12fc@mail.gmail.com> <87eiob8tpw.fsf@telefonica.net> Message-ID: <74c447500911070206n1bddca0el51b25ab6d6d7c2b7@mail.gmail.com> On Sat, Nov 7, 2009 at 12:32 AM, Chris Lattner wrote: > > On Nov 6, 2009, at 9:10 AM, ?scar Fuentes wrote: > >> Chandler Carruth writes: >> >>> FYI, I'll plan on removing this subtree on Monday of next week if no >>> one else chimes in requesting a reprieve... >> >> The Visual C++ project files are still there. >> >> Anyone objected by private e-mail? Can we know the reasons just in >> case >> we can enhance the cmake build on accordance? In the past, the only >> reason for not removing win32/ was that the cmake-generated project >> files are not relocatable. As the win32/ project files seem out of >> date >> for months now, I reckon that the user who had that requirement >> switched >> to cmake. > > Removed in r86358. ?I don't know what happened to Chandler. Sorry, fires broke out this week. Was going to do it this weekend, but you got there first. > > -Chris > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > From etherzhhb at gmail.com Sat Nov 7 06:38:18 2009 From: etherzhhb at gmail.com (ether zhhb) Date: Sat, 7 Nov 2009 20:38:18 +0800 Subject: [LLVMdev] llvm targeting EPIC architecture like IA-64 Message-ID: <5f72161f0911070438n6e5fb006p5d3391f3e912253d@mail.gmail.com> hi, everyone! i am going to writing a backend for architecture like IA-64. could i use the instruction selector to help me generate some instruction like bundles (long instruction words consisting of several microoperations)? or i have to handle it by my own machine code pass? thank you :) From rengolin at systemcall.org Sat Nov 7 18:15:53 2009 From: rengolin at systemcall.org (Renato Golin) Date: Sun, 8 Nov 2009 00:15:53 +0000 Subject: [LLVMdev] interesting preso In-Reply-To: <911B2C1C-9E37-4985-A8F1-B115446A1A48@apple.com> References: <911B2C1C-9E37-4985-A8F1-B115446A1A48@apple.com> Message-ID: 2009/11/7 Chris Lattner : > I enjoyed this presentation: > http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf Wow, very comprehensive! Is there anyone working on vectorization? This is something that interests me, I might give it a try, just need some pointers. cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From clattner at apple.com Sat Nov 7 20:07:29 2009 From: clattner at apple.com (Chris Lattner) Date: Sat, 7 Nov 2009 18:07:29 -0800 Subject: [LLVMdev] interesting preso In-Reply-To: References: <911B2C1C-9E37-4985-A8F1-B115446A1A48@apple.com> Message-ID: <063E1190-D1AF-4CB9-9401-034A55BCBAAD@apple.com> On Nov 7, 2009, at 4:15 PM, Renato Golin wrote: > 2009/11/7 Chris Lattner : >> I enjoyed this presentation: >> http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf > > Wow, very comprehensive! > > Is there anyone working on vectorization? This is something that > interests me, I might give it a try, just need some pointers. The first step is loop dependence analysis. This is required to determine loop reuse information and is the basis for a lot of vectorization and parallelization loop transformations. There is work in this area in mainline llvm, but I don't know the status of it. -Chris From rengolin at systemcall.org Sun Nov 8 05:59:25 2009 From: rengolin at systemcall.org (Renato Golin) Date: Sun, 8 Nov 2009 11:59:25 +0000 Subject: [LLVMdev] interesting preso In-Reply-To: <063E1190-D1AF-4CB9-9401-034A55BCBAAD@apple.com> References: <911B2C1C-9E37-4985-A8F1-B115446A1A48@apple.com> <063E1190-D1AF-4CB9-9401-034A55BCBAAD@apple.com> Message-ID: 2009/11/8 Chris Lattner : > The first step is loop dependence analysis. ?This is required to determine > loop reuse information and is the basis for a lot of vectorization and > parallelization loop transformations. I suppose all dependencies can be determined with function passes and module-wide analysis. LLVM does unroll small loops, but once the number of iterations is too big, it does not even attempts to unroll a multiple of the iterations. for(i=0;i<4;++i) unrolls to four flat calls but for(i=0;i<400;++i) doesn't unroll to 100 iterations of four flat calls... Is there any IR vectorial instruction? Or does it need to go as metadata for the codegen routines? So, instead of unrolling at the IR level, we could have some MISD/SIMD instructions with the whole range and let the codegen define what low-level instructions to use in each case. So, a processor without VFP would unroll the loop, while one with could use the VFP instructions instead of unrolling. Collapsing memset-like loop: multistore i32 %value, [ 400 x i32 ]* %array Collapsing memcpy-like loop: multicopy [ 400 x i32 ]* %orig, [ 400 x i32 ]* %dest Like the MSVC, we could also detect pointer copy loops and revert to a memcpy call. If a loop is called more than a few times, might be better (if space optimisations are not on) to create a region in memory to copy from with memcpy. This is particularly useful in repetitive calls to reset an array for the next iteration in a specific parallel computation. In that case, instead of creating new instructions, we could use those functions, inline them as often as possible and optimise them to VFP instructions later. cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From pekka.jaaskelainen at tut.fi Sun Nov 8 06:59:12 2009 From: pekka.jaaskelainen at tut.fi (=?ISO-8859-1?Q?Pekka_J=E4=E4skel=E4inen?=) Date: Sun, 08 Nov 2009 13:59:12 +0100 Subject: [LLVMdev] interesting preso In-Reply-To: References: <911B2C1C-9E37-4985-A8F1-B115446A1A48@apple.com> <063E1190-D1AF-4CB9-9401-034A55BCBAAD@apple.com> Message-ID: <4AF6C0A0.3090407@tut.fi> Renato Golin wrote: > LLVM does unroll small loops, but once the number of iterations is too > big, it does not even attempts to unroll a multiple of the iterations. Partial unrolling is supported by the unroller when using the additional -unroll-allow-partial switch (false by default). Works for me with LLVM 2.5. -- Pekka J??skel?inen From rengolin at systemcall.org Sun Nov 8 07:58:19 2009 From: rengolin at systemcall.org (Renato Golin) Date: Sun, 8 Nov 2009 13:58:19 +0000 Subject: [LLVMdev] interesting preso In-Reply-To: <4AF6C0A0.3090407@tut.fi> References: <911B2C1C-9E37-4985-A8F1-B115446A1A48@apple.com> <063E1190-D1AF-4CB9-9401-034A55BCBAAD@apple.com> <4AF6C0A0.3090407@tut.fi> Message-ID: 2009/11/8 Pekka J??skel?inen : > Partial unrolling is supported by the unroller when using the > additional -unroll-allow-partial switch (false by default). > Works for me with LLVM 2.5. I see, pardon my ignorance. Why isn't that part of -O3? cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm From baldrick at free.fr Sun Nov 8 10:49:50 2009 From: baldrick at free.fr (Duncan Sands) Date: Sun, 08 Nov 2009 17:49:50 +0100 Subject: [LLVMdev] llvm.global_ctors In-Reply-To: References: <400d33ea0911061122o2de2d56ap5f938f6a182262da@mail.gmail.com> Message-ID: <4AF6F6AE.6060103@free.fr> > No, the order to static ctors is undefined. There is special > "priority" attribute though. I don't remember whether we honor it or > not... http://llvm.org/bugs/show_bug.cgi?id=5329 From jyasskin at google.com Sun Nov 8 17:17:30 2009 From: jyasskin at google.com (Jeffrey Yasskin) Date: Sun, 8 Nov 2009 15:17:30 -0800 Subject: [LLVMdev] Could you add tests for dlsym stubs? Message-ID: Hi Nate. I've noticed that when I hardcode ExecutionEngine::areDlsymStubsEnabled() to always return false, check-lit still passes. I'm working on fixing a couple bugs in the JIT that involve changing how stubs are handled. I'm being careful around dlsym stubs, but I'm not perfect and may make a mistake. I'd really appreciate if you could add some tests for the code you added that would prevent me from accidentally breaking it. Thanks, Jeffrey From wendling at apple.com Sun Nov 8 18:20:43 2009 From: wendling at apple.com (Bill Wendling) Date: Sun, 8 Nov 2009 16:20:43 -0800 Subject: [LLVMdev] interesting preso In-Reply-To: <911B2C1C-9E37-4985-A8F1-B115446A1A48@apple.com> References: <911B2C1C-9E37-4985-A8F1-B115446A1A48@apple.com> Message-ID: On Nov 6, 2009, at 8:40 PM, Chris Lattner wrote: > I enjoyed this presentation: > http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf > > Among other things it lists small code sequences when compiled with a > small collection of compilers, including llvm 2.6. It looks like > there are several fairly obvious things we could do better... > The person should be lauded for saying that inline assembly isn't all it's cracked up to be, and should be avoided when possible. :-) -bw From victor.zverovich at googlemail.com Mon Nov 9 03:58:17 2009 From: victor.zverovich at googlemail.com (Victor Zverovich) Date: Mon, 9 Nov 2009 09:58:17 +0000 Subject: [LLVMdev] DenseMap iterator constness fix In-Reply-To: References: Message-ID: Reminding about the patches... Is there a problem with them or simply nobody have looked at them since? Victor 2009/11/4 Victor Zverovich > Good catch! I meant "for iterator" of course. Attached is a corrected patch > together with an old patch for clang just to keep them together. > Could someone commit these, please? > > Thanks, > Victor > > 2009/11/4 Jeffrey Yasskin > > + // Otherwise this is a copy constructor for const_iterator. >> >> Do you mean "for iterator"? >> >> Otherwise, looks good to me. If you can commit this, please do. >> Otherwise, someone else should as I'm not going to be around tomorrow. >> >> On Wed, Nov 4, 2009 at 12:27 AM, Victor Zverovich >> wrote: >> > Hi Jeffrey, >> > You are right that the generated copy constructor is used for >> > const_iterator. I have added a comment clarifying this. Also I have >> added >> > the tests you suggested and corrected the comparison operators. Please >> find >> > attached the updated patches. >> > Best regards, >> > Victor >> > 2009/11/3 Jeffrey Yasskin >> >> >> >> +template >> >> +struct If { typedef True Result; }; >> >> + >> >> +template >> >> +struct If { typedef False Result; }; >> >> >> >> These should probably go into include/llvm/Support/type_traits.h. In >> >> C++0x, this is named "conditional" (section 20.6.7), so I think you >> >> should use the same name, despite the standard committee's bad taste. >> >> >> >> + DenseMapIterator(const DenseMapIterator> >> + KeyInfoT, ValueInfoT, >> false>& >> >> I) >> >> >> >> This looks like it will make it impossible to copy const_iterators. I >> >> guess it doesn't because the copy-constructor is auto-generated, but >> >> please comment that and add tests for it and for the non-const->const >> >> conversion to unittests/ADT/DenseMapTest.cpp. >> >> >> >> Otherwise, the patches just change iterator to const_iterator, which >> looks >> >> fine. >> >> >> >> On Tue, Nov 3, 2009 at 3:09 AM, Victor Zverovich >> >> wrote: >> >> > Dear all, >> >> > The first of the proposed patches (DenseMapIterator.patch) forbids >> >> > implicit >> >> > conversion of DenseMap::const_iterator to DenseMap::iterator which >> was >> >> > possible because DenseMapIterator inherited (publicly) from >> >> > DenseMapConstIterator. Conversion the other way around is now allowed >> as >> >> > one >> >> > may expect. >> >> > The template DenseMapConstIterator is removed and the template >> >> > parameter IsConst which specifies whether the iterator is constant >> >> > is added >> >> > to DenseMapIterator. >> >> > Actually IsConst parameter is not necessary since the constness can >> be >> >> > determined from KeyT but this is not relevant to the fix and can be >> >> > addressed later. >> >> > The second patch (DenseMapIterator-clang.patch) corrects clang's >> usage >> >> > of >> >> > DenseMap iterators. >> >> > Best regards, >> >> > Victor >> >> > _______________________________________________ >> >> > LLVM Developers mailing list >> >> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > >> >> > >> > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091109/1577067e/attachment.html From j.prasanth.j at gmail.com Mon Nov 9 04:55:19 2009 From: j.prasanth.j at gmail.com (Prasanth J) Date: Mon, 9 Nov 2009 16:25:19 +0530 Subject: [LLVMdev] Compilation error while cross compiling LLVM for ARM Message-ID: Hi, i am a newbie to llvm architecture. i have been trying to port llvm on ARM target. i am using the following configuration for cross compiling llvm. ../llvm/configure --host=arm-linux --target=arm-linux --build=i686-linux --prefix=/opt/llvm-arm/ --enable-optimized --disable-debug \ --disable-expensive-checks --disable-doxygen \ --disable-threads --enable-targets=cbe,cpp,arm using this configuration i am facing the following compilation error. pls help me how to resolve this error.. *make[1]: Entering directory `/home/prasanth/LLVM_ARM/llvm-target/obj-new/lib/System' llvm[1]: Compiling Alarm.cpp for Release build llvm[1]: Compiling Atomic.cpp for Release build llvm[1]: Compiling Disassembler.cpp for Release build llvm[1]: Compiling DynamicLibrary.cpp for Release build llvm[1]: Compiling Errno.cpp for Release build llvm[1]: Compiling Host.cpp for Release build llvm[1]: Compiling IncludeFile.cpp for Release build llvm[1]: Compiling Memory.cpp for Release build /home/prasanth/LLVM_ARM/llvm-target/llvm/lib/System/Memory.cpp: In static member function ?static void llvm::sys::Memory::InvalidateInstructionCache(const void*, size_t)?: /home/prasanth/LLVM_ARM/llvm-target/llvm/lib/System/Memory.cpp:67: error: ?__clear_cache? was not declared in this scope make[1]: *** [/home/prasanth/LLVM_ARM/llvm-target/obj-new/lib/System/Release/Memory.o] Error 1 make[1]: Leaving directory `/home/prasanth/LLVM_ARM/llvm-target/obj-new/lib/System' make: *** [all] Error 1** *i can able to compile by commenting the line in Memory.cpp but i am not sure whether it will affect anything while running llvm on target. After cross-compilation i copied the binaries to target and i tried to compile and run a simple helloworld.c application. As clang requires a working gcc on target i used to "-ccc-clang-archs" options to skip the need for gcc on target. But still i am getting the following error. *# TMPDIR=/dtv/usb/sda ../bin/clang -ccc-clang-archs arm hello.c -v -I/dtv/usb/sda/LLVM/include clang version 1.0 (https://llvm.org/svn/llvm-project/cfe/branches/release_26exported) Target: arm-unknown-linux-gnu Thread model: posix "/dtv/usb/sda/LLVM/llvm-2.6-arm/bin/../libexec/clang-cc" -triple arm-unknown-linux-gnu -S -disable-free -main-file-name hello.c --relocation-mc clang-cc version 1.0 based upon llvm 2.6 hosted on arm-unknown-linux-gnu ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/include" ignoring nonexistent directory "/System/Library/Frameworks" ignoring nonexistent directory "/Library/Frameworks" #include "..." search starts here: #include <...> search starts here: /dtv/usb/sda/LLVM/include /dtv/usb/sda/LLVM/llvm-2.6-arm/lib/clang/1.0/include End of search list. clang-cc: /home/prasanth/LLVM_ARM/llvm-target/llvm-2.6/include/llvm/ADT/ilist.h:197: typename bidirectional_iterator::reference ll. 0 clang-cc 0x00cd314c Stack dump: 0. Program arguments: /dtv/usb/sda/LLVM/llvm-2.6-arm/bin/../libexec/clang-cc -triple arm-unknown-linux-gnu -S -disable-free -main-file-nam 1. parser at end of file 2. Code generation 3. Running pass 'ARM Instruction Selection' on function '@main' clang: error: compiler command failed due to signal 6 (use -v to see invocation) # *can anyone help me how to use clang for compiling applications on target. is it possible to run llvm bytecode on target using lli? if it is so pls let me know how to do it.. following are the target info: *target : arm cpu : arm1136jf-s toolchain : armv6* Thanks and Regards, Prasanth J -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091109/607514e1/attachment.html From xerxes at zafena.se Mon Nov 9 05:50:49 2009 From: xerxes at zafena.se (=?windows-1252?Q?Xerxes_R=E5nby?=) Date: Mon, 09 Nov 2009 12:50:49 +0100 Subject: [LLVMdev] Compilation error while cross compiling LLVM for ARM - the __clear_cache issue In-Reply-To: References: Message-ID: <4AF80219.6090809@zafena.se> Prasanth J skrev: > Hi, > > i am a newbie to llvm architecture. i have been trying to port llvm on > ARM target. i am using the following configuration for cross compiling > llvm. > > ../llvm/configure --host=arm-linux --target=arm-linux > --build=i686-linux --prefix=/opt/llvm-arm/ --enable-optimized > --disable-debug \ > --disable-expensive-checks --disable-doxygen \ > --disable-threads --enable-targets=cbe,cpp,arm > > using this configuration i am facing the following compilation error. > pls help me how to resolve this error.. > > /make[1]: Entering directory > `/home/prasanth/LLVM_ARM/llvm-target/obj-new/lib/System' > llvm[1]: Compiling Alarm.cpp for Release build > llvm[1]: Compiling Atomic.cpp for Release build > llvm[1]: Compiling Disassembler.cpp for Release build > llvm[1]: Compiling DynamicLibrary.cpp for Release build > llvm[1]: Compiling Errno.cpp for Release build > llvm[1]: Compiling Host.cpp for Release build > llvm[1]: Compiling IncludeFile.cpp for Release build > llvm[1]: Compiling Memory.cpp for Release build > /home/prasanth/LLVM_ARM/llvm-target/llvm/lib/System/Memory.cpp: In > static member function ?static void > llvm::sys::Memory::InvalidateInstructionCache(const void*, size_t)?: > /home/prasanth/LLVM_ARM/llvm-target/llvm/lib/System/Memory.cpp:67: > error: ?__clear_cache? was not declared in this scope > make[1]: *** > [/home/prasanth/LLVM_ARM/llvm-target/obj-new/lib/System/Release/Memory.o] > Error 1 > make[1]: Leaving directory > `/home/prasanth/LLVM_ARM/llvm-target/obj-new/lib/System' > make: *** [all] Error 1// > > /i can able to compile by commenting the line in Memory.cpp but i am > not sure whether it will affect anything while running llvm on target. > After cross-compilation i copied the binaries to target and i tried to > compile and run a simple helloworld.c application. As clang requires a > working gcc on target i used to "-ccc-clang-archs" options to skip the > need for gcc on target. But still i am getting the following error. By commenting out that line will make your llvm version crash sporadically since you would recreate llvm PR4960 if using the llvm JIT. http://llvm.org/bugs/show_bug.cgi?id=4960 __clear_cache are needed to clear the instructioncache after jitting a function and this gcc builtin are found in gcc 4.3.3 and later or CodeSourcery's 2007Q3/2008Q1 compiler releases and later. Try updating you cross compiler! Cheers Xerxes From mariusz.grad at googlemail.com Mon Nov 9 09:14:39 2009 From: mariusz.grad at googlemail.com (mg) Date: Mon, 9 Nov 2009 07:14:39 -0800 (PST) Subject: [LLVMdev] Cmake and pass Message-ID: Hi, Is it possible to generate pass (shared object) from Cmake? I tried to use add_llvm_library() however it produces only static libs. Thanks, Mariusz. From ofv at wanadoo.es Mon Nov 9 09:36:31 2009 From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=) Date: Mon, 09 Nov 2009 16:36:31 +0100 Subject: [LLVMdev] Cmake and pass References: Message-ID: <87vdhj7ls0.fsf@telefonica.net> mg writes: > Is it possible to generate pass (shared object) from Cmake? ? Please name the library or libraries you want to build as shared objects. > I tried to use add_llvm_library() however it produces only static > libs. As mentioned on http://www.llvm.org/docs/CMake.html : cmake -DBUILD_SHARED_LIBS=ON path/to/llvm/source This builds all LLVM libraries as shared objects, though. -- ?scar From kennethuil at gmail.com Mon Nov 9 09:58:18 2009 From: kennethuil at gmail.com (Kenneth Uildriks) Date: Mon, 9 Nov 2009 09:58:18 -0600 Subject: [LLVMdev] Proposal: intp type Message-ID: <400d33ea0911090758p889b240xff996305a70f78a3@mail.gmail.com> Simply put, it's a pointer-sized integer. I'm blatantly stealing this idea from .NET, where IntPtr (a pointer-sized integer) is a basic type. In my front end, I had considered just using a pointer for intp behind-the-scenes and doing conversion to/from int64 when I wanted to do arithmetic on them, but pointers and integers don't always align the same way. So what I really want is a way to represent in IR that a certain parameter/struct member is a pointer-sized integer. Now that optimizations work without target data, I think we're tantalizingly close to a situation where useful, target-independent IR files are a real possibility. intp is one of the remaining pieces of that puzzle; lots of native code expects an integer parameter/struct member sized the same as a pointer. It makes sense for sizes and offsets to be represented this way, and in a lot of cases, they are represented this way, and in IR a lot more would be represented this way if such a type existed. Also, having this type present will tend over time to reduce the number of casts to/from int64 appearing in bitcode that have to be stripped out, slightly speeding up optimizations and codegen. The ramifications that I see: 1. Conversions to/from other integer types: right now, integer type conversions are always explicity specified as either a trunc, a sext, or a zext. Since the size of intp is not known at IR generation time, you can't know whether a conversion to/from intp truncates or extends. 2. The usual ramifications of adding a new type: IR generation/analysis, optimizations, and codegen all have to be updated to deal with the existence of the new type. The changes should be minor; it's an integer type with all of the supported operations of integer types, with the only difference being that its size cannot be determined without target data. From gohman at apple.com Mon Nov 9 13:29:18 2009 From: gohman at apple.com (Dan Gohman) Date: Mon, 9 Nov 2009 11:29:18 -0800 Subject: [LLVMdev] BasicAliasAnalysis: Null pointers do not alias with anything In-Reply-To: <4AF5417A.9030600@hanshq.net> References: <4AF14E9B.9060209@hanshq.net> <4AF4458E.1050504@hanshq.net> <3CCEAD4B-9147-40FC-86F6-44B091204F4B@apple.com> <4AF5417A.9030600@hanshq.net> Message-ID: <82AEF5D8-2569-49F9-86E5-224A04255777@apple.com> On Nov 7, 2009, at 1:44 AM, Hans Wennborg wrote: > > > Dan Gohman wrote: >> On Nov 6, 2009, at 7:49 AM, Hans Wennborg wrote: >>> I'm not sure what you mean by generalizing. >>> Do you mean I should do the check on O1 and O2, which are the results of calls to getUnderlyingObject? >>> >>> Something like: >>> >>> if (const ConstantPointerNull *CPN = dyn_cast(O1)) >>> if (CPN->getType()->getAddressSpace() == 0) >>> return NoAlias; >>> >>> and the same for O2 (maybe extract it into a function?) >> Yes, thanks. > > Ok, patch with test case attached. Applied, thanks! Dan From gohman at apple.com Mon Nov 9 13:49:57 2009 From: gohman at apple.com (Dan Gohman) Date: Mon, 9 Nov 2009 11:49:57 -0800 Subject: [LLVMdev] MachineFunction::get In-Reply-To: <54a19460911061743g5ec8ce79o460c641eec992c62@mail.gmail.com> References: <54a19460911061743g5ec8ce79o460c641eec992c62@mail.gmail.com> Message-ID: <6940318C-7DF3-41CD-9214-60F265E05BE5@apple.com> On Nov 6, 2009, at 5:43 PM, Sumesh Udayakumaran wrote: > Hi > I have a ModulePass in LLC that runs after most of codegen completes, > right before OBJ emission. I want the ModulePass to iterate over all > MachineFunctions, emulating them. I used to do this by iterating over > all Module Function's, and using MachineFunction::get() to get the > MachineFunction associated with said Function. > > In LLVM 2.6, MachineFunction::get() is gone. What is the new way of > doing what I need? CodeGen doesn't attempt to keep the MachineFunctions for all the Functions allocated at the same time. Looking back at 2.5, it seems it may have been possible to get CodeGen to do this, though it was probably accidental. MachineFunctions are now allocated and deallocated with the MachineFunctionAnalysis pass. It's very straight-forward; it's just a FunctionPass which allocates a new MachineFunction in its runOnFunction and deallocates it in its releaseMemory. You may be able to change it to fit your needs. Dan From alysson.pina at gmail.com Mon Nov 9 14:22:01 2009 From: alysson.pina at gmail.com (Alysson) Date: Mon, 9 Nov 2009 17:22:01 -0300 Subject: [LLVMdev] Optimizing class casts away In-Reply-To: References: Message-ID: Dear all, I am trying to remove some instanceof tests from bc code that is produced by vmkit. For instance: 1 if (o instanceof String) { 2 String s = (String)o; 3 } Vmkit seems to be inserting two tests into the bc code: one for the test in line 1, and another, implicit, that would lunch perhaps JavaClassCastException if the cast fails at runtime. Would it be possible for some of you guys more familiar with vmkit to explain me how it produces code for these casts and tests? I have separated two CFG's. The first hereis for the program below: public class J2 { Object o = new String; } The second CFG hereis for the same program, without the cast: public class J1 { Object o = new String; String s = (String)o; } Could some of you give me an idea of how the extra code would look like? It seems that the CFG's are a bit big for such small programs. All the best, Alysson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091109/72b9ffb6/attachment.html From mariusz.grad at googlemail.com Mon Nov 9 14:27:31 2009 From: mariusz.grad at googlemail.com (mg) Date: Mon, 9 Nov 2009 12:27:31 -0800 (PST) Subject: [LLVMdev] Cmake and pass In-Reply-To: <87vdhj7ls0.fsf@telefonica.net> References: <87vdhj7ls0.fsf@telefonica.net> Message-ID: On Nov 9, 4:36?pm, ?scar Fuentes wrote: > cmake -DBUILD_SHARED_LIBS=ON path/to/llvm/source > > This builds all LLVM libraries as shared objects, though. Works great. Thank You. CMakeLists.txt looks like this: set(BUILD_SHARED_LIBS "ON") add_llvm_library(LLVMfoo pass/main.cc) It generates Debug/lib/libLLVMfoo.so which then can be loaded with opt -load. -- mg. From neelnagar42 at gmail.com Mon Nov 9 18:34:54 2009 From: neelnagar42 at gmail.com (Neel Nagar) Date: Tue, 10 Nov 2009 00:34:54 +0000 Subject: [LLVMdev] speed up memcpy intrinsic using ARM Neon registers Message-ID: <503ab6d60911091634n2360b086g1935924bc27fd3c4@mail.gmail.com> I tried to speed up Dhrystone on ARM Cortex-A8 by optimizing the memcpy intrinsic. I used the Neon load multiple instruction to move up to 48 bytes at a time . Over 15 scalar instructions collapsed down into these 2 Neon instructions. fldmiad r3, {d0, d1, d2, d3, d4, d5} @ SrcLine dhrystone.c 359 fstmiad r1, {d0, d1, d2, d3, d4, d5} It seems like this should be faster. But I did not see any appreciable speedup. I think the patch is correct. The code runs fine. I have attached my patch for "lib/Target/ARM/ARMISelLowering.cpp" to this email. Does this look like the right modification? Does anyone have any insights into why this is not way faster than using scalar registers? I am using a BeagleBoard. Thanks, Neel Nagar -------------- next part -------------- A non-text attachment was scrubbed... Name: memcpy_neon_091109.patch Type: application/octet-stream Size: 2039 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091110/61765619/attachment.obj From jyasskin at google.com Mon Nov 9 19:19:18 2009 From: jyasskin at google.com (Jeffrey Yasskin) Date: Mon, 9 Nov 2009 17:19:18 -0800 Subject: [LLVMdev] DenseMap iterator constness fix In-Reply-To: References: Message-ID: Whoops! Thanks for the ping! I've committed your patches as r86636 and r86638. On Mon, Nov 9, 2009 at 1:58 AM, Victor Zverovich wrote: > Reminding about the patches... > Is there a problem with them or simply nobody have looked at them since? > > Victor > > 2009/11/4 Victor Zverovich >> >> Good catch! I meant "for iterator" of course. Attached is a corrected >> patch together with an old patch for clang just to keep them together. >> Could someone commit these, please? >> Thanks, >> Victor >> 2009/11/4 Jeffrey Yasskin >>> >>> + ?// Otherwise this is a copy constructor for const_iterator. >>> >>> Do you mean "for iterator"? >>> >>> Otherwise, looks good to me. If you can commit this, please do. >>> Otherwise, someone else should as I'm not going to be around tomorrow. >>> >>> On Wed, Nov 4, 2009 at 12:27 AM, Victor Zverovich >>> wrote: >>> > Hi Jeffrey, >>> > You are right that the generated copy constructor is used for >>> > const_iterator. I have added a comment clarifying this. Also I have >>> > added >>> > the tests you suggested and corrected the comparison operators.?Please >>> > find >>> > attached the updated patches. >>> > Best regards, >>> > Victor >>> > 2009/11/3 Jeffrey Yasskin >>> >> >>> >> +template >>> >> +struct If { typedef True Result; }; >>> >> + >>> >> +template >>> >> +struct If { typedef False Result; }; >>> >> >>> >> These should probably go into include/llvm/Support/type_traits.h. In >>> >> C++0x, this is named "conditional" (section 20.6.7), so I think you >>> >> should use the same name, despite the standard committee's bad taste. >>> >> >>> >> + ?DenseMapIterator(const DenseMapIterator>> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?KeyInfoT, ValueInfoT, >>> >> false>& >>> >> I) >>> >> >>> >> This looks like it will make it impossible to copy const_iterators. I >>> >> guess it doesn't because the copy-constructor is auto-generated, but >>> >> please comment that and add tests for it and for the non-const->const >>> >> conversion to unittests/ADT/DenseMapTest.cpp. >>> >> >>> >> Otherwise, the patches just change iterator to const_iterator, which >>> >> looks >>> >> fine. >>> >> >>> >> On Tue, Nov 3, 2009 at 3:09 AM, Victor Zverovich >>> >> wrote: >>> >> > Dear all, >>> >> > The first of the proposed patches (DenseMapIterator.patch) forbids >>> >> > implicit >>> >> > conversion of DenseMap::const_iterator to DenseMap::iterator which >>> >> > was >>> >> > possible because DenseMapIterator inherited (publicly) from >>> >> > DenseMapConstIterator. Conversion the other way around is now >>> >> > allowed as >>> >> > one >>> >> > may expect. >>> >> > The template DenseMapConstIterator is?removed and the template >>> >> > parameter?IsConst which specifies whether the iterator is constant >>> >> > is?added >>> >> > to?DenseMapIterator. >>> >> > Actually IsConst parameter is not necessary since the constness can >>> >> > be >>> >> > determined from KeyT but this is not relevant to the fix and can be >>> >> > addressed later. >>> >> > The second patch (DenseMapIterator-clang.patch) corrects clang's >>> >> > usage >>> >> > of >>> >> > DenseMap iterators. >>> >> > Best regards, >>> >> > Victor >>> >> > _______________________________________________ >>> >> > LLVM Developers mailing list >>> >> > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu >>> >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> > >>> >> > >>> > >>> > >> > > From lessen42 at gmail.com Mon Nov 9 19:59:07 2009 From: lessen42 at gmail.com (David Conrad) Date: Mon, 9 Nov 2009 20:59:07 -0500 Subject: [LLVMdev] speed up memcpy intrinsic using ARM Neon registers In-Reply-To: <503ab6d60911091634n2360b086g1935924bc27fd3c4@mail.gmail.com> References: <503ab6d60911091634n2360b086g1935924bc27fd3c4@mail.gmail.com> Message-ID: On Nov 9, 2009, at 7:34 PM, Neel Nagar wrote: > I tried to speed up Dhrystone on ARM Cortex-A8 by optimizing the > memcpy intrinsic. I used the Neon load multiple instruction to move up > to 48 bytes at a time . Over 15 scalar instructions collapsed down > into these 2 Neon instructions. > > fldmiad r3, {d0, d1, d2, d3, d4, d5} @ SrcLine dhrystone.c 359 > fstmiad r1, {d0, d1, d2, d3, d4, d5} > > It seems like this should be faster. But I did not see any > appreciable speedup. > > I think the patch is correct. The code runs fine. > > I have attached my patch for "lib/Target/ARM/ARMISelLowering.cpp" to > this email. > > Does this look like the right modification? > > Does anyone have any insights into why this is not way faster than > using scalar registers? On the A8, an ARM store after NEON stores to the same 16-byte block incurs a ~20 cycle penalty since the NEON unit executes behind ARM. It's worse if the NEON store was split across a 16-byte boundary, then there could be a 50 cycle stall. See http://hardwarebug.org/2008/12/31/arm-neon-memory-hazards/ for some more details and benchmarks. From dalej at apple.com Mon Nov 9 20:11:34 2009 From: dalej at apple.com (Dale Johannesen) Date: Mon, 9 Nov 2009 18:11:34 -0800 Subject: [LLVMdev] Altivec vs the type legalizer Message-ID: PPC Altivec supports vector type v16i8 (and others) where the element type is not legal (in llvm's implementation). When we have a BUILD_VECTOR of these types with constant elements, LegalizeTypes first promotes the element types to i32, then builds a constant pool entry of type v16i32. This is wrong. I can fix it by truncating the elements back to i8 in ExpandBUILD_VECTOR. Does this seem like the right approach? I ask because we'll be relying on ConstantVector::get and getConstantPool to work even with elements of a type that's illegal for the target; currently, they do. (And I see no other way to fix it except to break the vector into scalars, which produces horrendous code.) typedef vector unsigned char vuint8_t; vuint8_t baz; void foo(vuint8_t x) { vuint8_t temp = (vuint8_t)(22,21,20, 3, 25,24,23, 3, 28,27,26, 3, 31,30,29, 3); baz = vec_add(x, temp); } From baldrick at free.fr Mon Nov 9 20:33:53 2009 From: baldrick at free.fr (Duncan Sands) Date: Tue, 10 Nov 2009 03:33:53 +0100 Subject: [LLVMdev] Altivec vs the type legalizer In-Reply-To: References: