similar to: [LLVMdev] technical debt

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 kotler<rkotler at mips.com> wrote: >> something to think about as llvm and clang grows. >> >> http://en.wikipedia.org/wiki/Technical_debt >> _______________________________________________ >>

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

Can we get back to the substantive discussion about your ideas for lessening the technical debt? On Mon, Jun 4, 2012 at 8:05 PM, reed kotler <rkotler at mips.com> wrote: > 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

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 kotler<rkotler at mips.com>  wrote: >>> >>> something to think about as llvm and clang grows.

I'm pretty sure neither llvm nor clang have any technical debt at all. On Mon, Jun 4, 2012 at 5:18 PM, reed kotler <rkotler at mips.com> wrote: > something to think about as llvm and clang grows. > > http://en.wikipedia.org/wiki/Technical_debt > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu        

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

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,

Hi Sean, Glad to hear there is clean up of tablegen going on. Just for the record, I don't know what you are referring to regarding some comment of mine at my talk about 10K LOC. I don't know how big tablegen is itself nor how much code has been written in it so I would not have ventured such a guess. The idea of totally replacing the tablegen language came up at the talk during the

I definitely trust what you say now with time to think at your keyboard over what you said on the spot in a live presentation. The comment that I was referring to was: 36:44 of http://llvm.org/devmtg/2012-04-12/videos/Reed_Kotler-mobile.mov "there's not really more than a couple thousand lines of .td ... I mean there's not tons of this code so if we had to use a different one I

On 04/24/2013 07:39 PM, Chris Lattner wrote: > On Apr 24, 2013, at 6:27 PM, Reed Kotler <rkotler at mips.com> wrote: >> I would really push towards doing this in LLVM IR as the next step. > > What makes you say that? > >> It's possible that what you are proposing is the right "long term" solution but I think it's not a good evolutionary approach;

Did you agree with the comment about the use of long long from the tool? Anyway, it's not really important to me that we adopt any specific google code rules over the current llvm rule. The point is to that Google has a deeper set of conventions and it would be a good starting point for us. Also, they have a tool which checks a lot of this. The lack of a tool for llvm style check is what

On Apr 24, 2013, at 6:27 PM, Reed Kotler <rkotler at mips.com> wrote: > I would really push towards doing this in LLVM IR as the next step. What makes you say that? > It's possible that what you are proposing is the right "long term" solution but I think it's not a good evolutionary approach; it's more revolutionary. Doing this in LLVM IR seems like a major

Hi Reed, Sent from my iPad On Apr 25, 2013, at 3:46 PM, Reed Kotler <rkotler at mips.com> wrote: > On 04/24/2013 07:39 PM, Chris Lattner wrote: >> On Apr 24, 2013, at 6:27 PM, Reed Kotler <rkotler at mips.com> wrote: >>> I would really push towards doing this in LLVM IR as the next step. >> >> What makes you say that? >> >>> It's

On 04/24/2013 05:26 PM, Chris Lattner wrote: > On Apr 24, 2013, at 5:01 PM, Dan Gohman <dan433584 at gmail.com> wrote: >> In the spirit of the (long-term) intent to migrate away from the SelectionDAG framework, it is desirable to implement legalization passes as discrete passes. Attached is a patch which implements the beginning of a new type legalization pass, to help motivate

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 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.