similar to: [LLVMdev] Self hosting LLVM

Displaying 20 results from an estimated 50000 matches similar to: "[LLVMdev] Self hosting LLVM"

2006 Oct 20
0
[LLVMdev] Self hosting LLVM
Devang, On Fri, 2006-10-20 at 11:14 -0700, Devang Patel wrote: > Hi All, > > Now, as of yesterday evening, I am able to self host llvm in Release > mode on PowerPC and X86! > > This means, llvm itself is compiled using llvm optimizer and code > generator (instead of GCC) and generated llvm passes all tests in llvm/ > test directory. Great! That's wonderful
2007 Apr 19
2
[LLVMdev] llvm-gcc won't bootstrap
Got a strange problem. With our modified llvm here,llvm-gcc won't bootstrap. It fails compiling unwind-dw2.c during translation from the gcc IR to llvm. It fails with -O0 -emit-llvm so according to the docs, this is strictly a frontend bug. A run of delta produced an 18 line testcase with nothing remarkable in it. However, it bootstraps fine using the official llvm sources. Note that the
2010 Oct 10
2
[LLVMdev] More DIFactory questions - still stumped
BTW, the reason I stopped responding to this thread is not because I solved the problem, but because I simply gave up and decided to work on other things for a while since I was making no progress. Having finished those other things (the stack crawler, for one), I'm hoping that time and a fresh start will yield better results. Unfortunately after about a day spent reviewing old llvm-dev
2011 Dec 16
3
[LLVMdev] llvm/clang test failures on powerpc-darwin8
>> These results have far fewer failures than svn-trunk, and are also >> comparable to bootstrapping with gcc-4.6.2, summarized here: >> http://paste.lisp.org/display/126363 >> (Unfortunately, I no longer have the whole build/test log for the gcc46 bootstrap.) >> This consistency between different bootstraps of the release gives me >> some hope that g++-4.0.1 is
2007 Jun 21
0
[LLVMdev] hacked up llvm-gcc bootstraps on linux-x86_64
On Thu, 21 Jun 2007, [UTF-8] Rafael Esp?ndola wrote: > Bugs 1519 and 1521 currently prevent a clean bootstrap on Linux > x86_64. I was able to hack it to work :-) > > The attached patch includes two parts. One is a tentative fix bug > 1519: just set LastFieldStartsAtNonByteBoundry in > allFieldsAreNotBitFields. Cool, I'll let Duncan or Devang comment on this patch, it looks
2010 Oct 11
0
[LLVMdev] More DIFactory questions - still stumped
On Sun, Oct 10, 2010 at 9:54 AM, Talin <viridia at gmail.com> wrote: > BTW, the reason I stopped responding to this thread is not because I solved > the problem, but because I simply gave up and decided to work on other > things for a while since I was making no progress. Having finished those > other things (the stack crawler, for one), I'm hoping that time and a fresh >
2011 Dec 16
3
[LLVMdev] llvm/clang test failures on powerpc-darwin8
Hi, Thanks for the quick reply again. > On Thu, Dec 15, 2011 at 1:17 PM, David Fang <fang at csl.cornell.edu> wrote: >> Hi, >> >> I've bootstrapped llvm/clang from svn-trunk on powerpc-darwin8 (g++-4.0.1), and >> have the following test results to share. >> Summary below, full log at: >>
2010 Sep 07
0
[LLVMdev] More DIFactory questions - still stumped
On Sep 7, 2010, at 9:11 AM, Renato Golin wrote: > On 7 September 2010 16:49, Devang Patel <dpatel at apple.com> wrote: >> Your recent changes mentioned below would change correctness of debug info, >> but it would unlikely to impact structure of DWARF generated. And somehow, >> this structure is invalid in your case. > > I was hoping for a quick-fix on the
2010 Sep 07
2
[LLVMdev] More DIFactory questions - still stumped
On 7 September 2010 16:49, Devang Patel <dpatel at apple.com> wrote: > Your recent changes mentioned below would change correctness of debug info, > but it would unlikely to impact structure of DWARF generated. And somehow, > this structure is invalid in your case. I was hoping for a quick-fix on the assumptions of DwarfDebug about Subprograms' MDNodes, but it might be
2009 Jan 08
2
[LLVMdev] Loop elimination with floating point counter.
Hi Devang, Thanks. Yes, in the case variable i incremented by 1.0f is optimized. I don't know why... Anyway, I've filed this problem into bugzilla(Bug 3299) -- Syoyo On Fri, Jan 9, 2009 at 12:42 AM, Devang Patel <dpatel at apple.com> wrote: > > On Jan 8, 2009, at 4:36 AM, Syoyo Fujita wrote: > >> Hi LLVM-ers, >> >> I'd like to eliminate dead loop
2012 Jan 27
0
[LLVMdev] [RFC] Module Flags Metadata
[ removing cfe-dev from the cc list ] On Jan 27, 2012, at 1:31 PM, Dan Gohman wrote: > On Jan 27, 2012, at 11:20 AM, Devang Patel wrote: > >> >> On Jan 26, 2012, at 2:10 PM, Dan Gohman wrote: >> >>> On Jan 26, 2012, at 12:54 PM, Devang Patel wrote: >>>> >>>> On Jan 26, 2012, at 11:15 AM, Dan Gohman wrote: >>>>
2010 Oct 13
2
[LLVMdev] Possibility of Corruption of debug metadata
Hi Devang, Is there any particular reason as to why debug info support for tls hasn't been implemented. Is the feature in pipeline ? How hard is it to implement ? On Wed, Oct 13, 2010 at 4:12 PM, Devang Patel <dpatel at apple.com> wrote: > > On Oct 13, 2010, at 10:09 AM, shankha wrote: > > Hi Devang, > > On Wed, Oct 13, 2010 at 12:44 PM, Devang Patel <dpatel at
2012 Jan 27
3
[LLVMdev] [cfe-dev] [RFC] Module Flags Metadata
On Jan 27, 2012, at 11:20 AM, Devang Patel wrote: > > On Jan 26, 2012, at 2:10 PM, Dan Gohman wrote: > >> On Jan 26, 2012, at 12:54 PM, Devang Patel wrote: >>> >>> On Jan 26, 2012, at 11:15 AM, Dan Gohman wrote: >>> >>>> or what optimizers must do to preserve it. >>> >>> The number one reason behind metadata is to have a
2008 Jul 03
3
[LLVMdev] gcc in c++
On Thu, Jul 3, 2008 at 9:09 AM, Devang Patel <dpatel at apple.com> wrote: >> On Wed, Jul 2, 2008 at 7:00 PM, Mike Stump <mrs at apple.com> wrote: >>> If we apply their logic to llvm, we can dominate, if we just target 8 >>> cores. :-) > > Does this mean llvm can not dominate if llvm target 1 core machine > also ? Making an optimizer/code generator
2008 Jul 03
0
[LLVMdev] llvm and parallel [Re: gcc in c++]
On Jul 3, 2008, at 10:28 AM, Eli Friedman wrote: > On Thu, Jul 3, 2008 at 9:09 AM, Devang Patel <dpatel at apple.com> wrote: >>> On Wed, Jul 2, 2008 at 7:00 PM, Mike Stump <mrs at apple.com> wrote: >>>> If we apply their logic to llvm, we can dominate, if we just >>>> target 8 >>>> cores. :-) >> >> Does this mean llvm can
2008 Mar 18
0
[LLVMdev] Array Dependence Analysis
On Mar 18, 2008, at 8:03 AM, Wojciech Matyjewicz wrote: > Hi, > > Devang Patel wrote: >> LLVM loop transformer operates at loop level, which is not what many >> optimizers do in general. So, a loop level interface (i.e. based on >> LoopPass in llvm) to find loop-carried dependence is preferable to >> loop optimizer. > > Do you mean making Array Dependence
2012 Feb 21
1
[LLVMdev] generating !llvm.dbg.sp
I've opened PR 12050 to track the problem with llvm.dbg.gv Eli From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Bendersky, Eli Sent: Tuesday, February 14, 2012 13:45 To: Devang Patel; Eric Christopher Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] generating !llvm.dbg.sp Eric, Devang, FYI exactly the same applies for llvm.dbg.gv - it's also
2012 Feb 14
0
[LLVMdev] generating !llvm.dbg.sp
Eric, Devang, FYI exactly the same applies for llvm.dbg.gv - it's also still listed in the docs and in various places throughout the code, although no longer generated. Eli From: Devang Patel [mailto:dpatel at apple.com] Sent: Monday, February 13, 2012 19:26 To: Eric Christopher Cc: Bendersky, Eli; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] generating !llvm.dbg.sp Thanks Eric. I know
2007 Jun 21
3
[LLVMdev] hacked up llvm-gcc bootstraps on linux-x86_64
Bugs 1519 and 1521 currently prevent a clean bootstrap on Linux x86_64. I was able to hack it to work :-) The attached patch includes two parts. One is a tentative fix bug 1519: just set LastFieldStartsAtNonByteBoundry in allFieldsAreNotBitFields. The other one is a plain hack. llvm-gcc and gcc disagree on how to pass some structures, so stage2 gcc fails to use the libcpp compiled by gcc. So I
2008 Oct 08
0
[LLVMdev] Error while making new pass
On Oct 8, 2008, at 10:59 AM, kapil anand wrote: > Hi Devang, > > GlobalModRefPass is also a ModulePass and it uses CallGraph Analysis. > So, I think it should not necessary to extend CallGraphSCCPass to use > CallGraph information. Module Pass shoule be sufficient... ok, but you're Registering your pass in CallGraph Analysis group. What if you remove