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