similar to: [LLVMdev] issues for mac os building llvm?

On Thu, Jul 18, 2013 at 4:29 PM, reed kotler <rkotler at mips.com> wrote: > I built llvm and clang on my home mac which has just a normal mac os file > system and everything seem to build just fine. > > Are there any requirements for needing linux style upper/lowercase file > systems for llvm/clang tool chains? Umm, are you unhappy that it works? :) -Eli

On 07/18/2013 04:39 PM, Eli Friedman wrote: > On Thu, Jul 18, 2013 at 4:29 PM, reed kotler <rkotler at mips.com> wrote: >> I built llvm and clang on my home mac which has just a normal mac os file >> system and everything seem to build just fine. >> >> Are there any requirements for needing linux style upper/lowercase file >> systems for llvm/clang tool

We have a large bitcode file produced from a tool. It's about 23 meg. When we compile this with llc, the footprint is 4-7 gig depending on which target. On a desktop this is not such a problem but it is on mobile devices. The suspect is that the flow graph for the entire program is built and kept for the duration, even if no optimization needing it all is in progress. This would make us

When I use -Os with a clang that implicitly calls llc, I get much different code than when call clang first with -Os and then call llc. How do I get these two paths to generate the same code? Tia. Reed

On 02/23/2013 04:28 AM, David Chisnall wrote: > Hi Reed, > > -Os could do with some love. It is more or less the same set of passes as -O2, but with a few things that are most likely to increase code size removed. We have had problems with it in the past for FreeBSD's bootloader. By tweaking the set of default passes added for -Os, I got the size down by about 20%, but I didn't

At one of the BOFS during the llvm conference a few years back, one of the Apple managers stated in effect that their view of -Os was to get some modest savings but only if performance has near 0 impact. On 02/23/2013 09:45 AM, Reed Kotler wrote: > On 02/23/2013 04:28 AM, David Chisnall wrote: >> Hi Reed, >> >> -Os could do with some love. It is more or less the same set

Mips 16 is basically to save space. I want to start comparing real benchmarks with llvm and gcc -mips16. Does -Os have any meaning currently to clang? llvm? What about inlining? Is inlining turned off? Tia. Reed

On 02/25/2014 02:38 PM, Eric Christopher wrote: > On Tue, Feb 25, 2014 at 2:32 PM, reed kotler <rkotler at mips.com> wrote: >> On 02/25/2014 09:30 AM, Richard Sandiford wrote: >>> reed kotler <rkotler at mips.com> writes: >>>> On 02/24/2014 04:42 PM, Eric Christopher wrote: >>>>> On Mon, Feb 24, 2014 at 4:40 PM, reed kotler <rkotler at

I see what my problem is here.... I'll continue to move further. Seems like Richards fix is still okay. On 02/25/2014 02:42 PM, Eric Christopher wrote: > On Tue, Feb 25, 2014 at 2:41 PM, reed kotler <rkotler at mips.com> wrote: >> On 02/25/2014 02:38 PM, Eric Christopher wrote: >>> On Tue, Feb 25, 2014 at 2:32 PM, reed kotler <rkotler at mips.com> wrote:

On Thu, Nov 3, 2011 at 3:02 PM, reed kotler <rkotler at mips.com> wrote: > We have a large bitcode file produced from a tool. It's about 23 meg. > > When we compile this with llc, the footprint is 4-7 gig depending on > which target. > > On a desktop this is not such a problem but it is on mobile devices. > > The suspect is that the flow graph for the entire

In case anyone is interested.... We don't need to compile llvm/clang using gcc anymore for the building of mips hosted llvm compilers. We build a linux mips hosted compiler starting with llvm/clang on x86 linux using the normal configure scripts and then can use that resulting compiler to build further llvm/clang native compilers on the mips linux host. The cross compiler and native

On 02/24/2014 04:42 PM, Eric Christopher wrote: > On Mon, Feb 24, 2014 at 4:40 PM, reed kotler <rkotler at mips.com> wrote: >> I need to leave soon and will take a look in the morning. >> >> I did look at the autoconf input files configure.ac >> >> There is a disable-zlib but not a disable-valgrind, even though it seems >> like there used to be.

In the following example with gcc style builtins, in once case llvm.powi.f64 is emitted and in the other just a call to library function powf. ~/llvm/build/Debug+Asserts/bin/clang -S -emit-llvm pow1.c Why is that? Is there a way to force the call to an llvm style builtin? Tia. Reed -------------- next part -------------- A non-text attachment was scrubbed... Name: pow1.c Type: text/x-csrc

On 02/25/2014 09:30 AM, Richard Sandiford wrote: > reed kotler <rkotler at mips.com> writes: >> On 02/24/2014 04:42 PM, Eric Christopher wrote: >>> On Mon, Feb 24, 2014 at 4:40 PM, reed kotler <rkotler at mips.com> wrote: >>>> I need to leave soon and will take a look in the morning. >>>> >>>> I did look at the autoconf input files

If you can't make an executable test from C or C++ code then how do you know something works. Just by examination of the .s? On 09/30/2014 03:18 PM, Reed Kotler wrote: > If I wanted to call this function that they generated by hand, from C or > C+ code, how would that be done? > > if have seen cases where a real boolean gets generated but it was > something fairly involved.

On 06/04/2012 05:17 PM, Daniel Berlin wrote: > Can we get back to the substantive discussion about your ideas for > lessening the technical debt? The lessening requires enlisting people that are willing to do this as opposed to doing fun science like cool optimization. I,for example, find the documentaiton, cleanup and refactoring to be interesting so I don't feel cheated to work on

On 06/10/2014 05:51 PM, Pete Cooper wrote: > Hi Reed > > You can do this on the instruction itself by telling it 2 operands > must be the same register. For example, from X86: > > let Constraints = "$src1 = $dst" in > defm INSERTPS : SS41I_insertf32<0x21, "insertps">; > > Thanks, Hi Pete, Sorry. I should have been more specific. I'm

Well, differences of opinion is what makes horse races. Reed On 06/04/2012 04:57 PM, Daniel Berlin wrote: > On Mon, Jun 4, 2012 at 7:53 PM, reed kotler<rkotler at mips.com> wrote: >> On 06/04/2012 03:25 PM, Daniel Berlin wrote: >>> I'm pretty sure neither llvm nor clang have any technical debt at all. >>> >>> On Mon, Jun 4, 2012 at 5:18 PM, reed

I would like to make the following member of AsmPrinter be protected void EmitInlineAsm(StringRef Str, const MDNode *LocMDNode = 0, InlineAsm::AsmDialect AsmDialect = InlineAsm::AD_ATT) const; I have some stubs that I want to emit in MipsAsmParser . Are there any objections to doing this? Reed

FWIW, I'm putting together (hopefully to be done by the end of this weekend) a substantial refactoring of the TableGen backend API along with shiny new documentation (reStructuredText with sphinx) of all of TableGen, including documentation about how to write backends and---depending on how adventurous I get---a more detailed coverage of the syntax. Also, Reed, in your TableGen talk, IIRC,