search for: davez

...le format is an _intermediate_ data structure designed to make creating the final executable straightforward and fast. It isn't designed to be an executable format itself. In fact, the reason why linkers can often be slow is because the intermediate and final object file formats are conflated. davez On May 2, 2012, at 8:29 AM, Shea Levy <shea at shealevy.com> wrote: > Hello, > > Would it be feasible to use the internal lld file format as the native > executable format for an OS? Are there performance or space > considerations that would make this a poor choice? >...

...kers can often be slow is because the intermediate and final object file formats are conflated. Hm, OK. Does the target executable format play a role in the intermediate steps the linker takes? That is, are there certain features or optimizations that only work for specific target formats? > davez > > > On May 2, 2012, at 8:29 AM, Shea Levy<shea at shealevy.com> wrote: > >> Hello, >> >> Would it be feasible to use the internal lld file format as the native >> executable format for an OS? Are there performance or space >> considerations that wo...

Hello, Would it be feasible to use the internal lld file format as the native executable format for an OS? Are there performance or space considerations that would make this a poor choice? Cheers, Shea Levy P.S. please CC me on replies, I'm not subscribed.

...ong term topic branches before proposing/integrating them into the public repository. If the conversion changes the SHA1 of commits (and it likely will due to goal #4), then these organizations will need time to prepare for the conversion (to avoid unscheduled downtime and/or any loss of history). davez

Hi Jeff, > I'm seeing LLVM (v 3.1) abort when trying to generate code that > multiplies or divides 128-bit integers on x86-32. this is a known issue. The runtime library (libgcc) has routines for dividing two 64-bit integers on x86-32, but not two 128-bit integers. At least, that is how it was last time I looked. To overcome this libgcc or LLVM's compiler-rt would need to get

Hello everybody, I'm seeing LLVM (v 3.1) abort when trying to generate code that multiplies or divides 128-bit integers on x86-32. Here is a complete example function: define %jl_value_t* @foo564(%jl_value_t*, %jl_value_t**, i32) { top: %3 = load %jl_value_t** %1, align 4, !dbg !5139 %4 = getelementptr inbounds %jl_value_t* %3, i32 0, i32 0, !dbg !5139 %5 = getelementptr %jl_value_t**

> On Aug 18, 2011, at 10:57 AM, David Greene wrote: >> >> Did the project ever come to a decision about making a transition to >> git? I'm trying to do some longer-term planning and it would be helpful >> to know what the roadmap is. It's stuck on: 1) A misunderstanding that global revision numbers are necessary and that 'git describe' along with