similar to: [LLVMdev] ArmConstantPoolValue

//===----------------------------------------------------------------------===// // FalseParser //===----------------------------------------------------------------------===// class FalseParser : public parser<bool> { public: explicit FalseParser(Option &O) : parser<bool>(O) { } // parse - Return true on error. bool parse(cl::Option& O, StringRef ArgName, StringRef

One could argue that mclinker is doing something good or not by how it's using this class but I don't see the need for parser<bool> to be final. That is a subjective opinion that mclinker needs to be changed. I think that "final" was added to some of these command line classes to avoid some kind of clang warning. That seems wrong to me that the tools are dictating

On 03/19/2015 08:55 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 4:30 AM, Reed Kotler <Reed.Kotler at imgtec.com > <mailto:Reed.Kotler at imgtec.com>> wrote: > > One could argue that mclinker is doing something good or not by > how it's using this class > but I don't see the need for parser<bool> to be final. That is a >

Well, you are an mclinker contributor and Google uses mclinker and now it's broken as the result of your change. I still don't see any justification to making a change in a public interface that is used by other non LLVM projects to fix some issue with clang warnings. People should be able to derive from those classes. I can't understand your reasoning as to why these classes must

On 03/19/2015 09:24 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 9:18 AM, Reed Kotler <reed.kotler at imgtec.com > <mailto:reed.kotler at imgtec.com>> wrote: > > Well, you are an mclinker contributor > > > Me personally? Not that I know of. Sorry. I thought i had seen your name in an mclinker commit. > > and Google uses mclinker >

On 03/19/2015 09:38 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 9:34 AM, Reed Kotler <reed.kotler at imgtec.com > <mailto:reed.kotler at imgtec.com>> wrote: > > On 03/19/2015 09:24 AM, David Blaikie wrote: >> >> >> On Thu, Mar 19, 2015 at 9:18 AM, Reed Kotler >> <reed.kotler at imgtec.com <mailto:reed.kotler at

On 03/19/2015 09:57 AM, David Blaikie wrote: > > > On Thu, Mar 19, 2015 at 9:52 AM, Reed Kotler <reed.kotler at imgtec.com > <mailto:reed.kotler at imgtec.com>> wrote: > > On 03/19/2015 09:38 AM, David Blaikie wrote: >> >> >> On Thu, Mar 19, 2015 at 9:34 AM, Reed Kotler >> <reed.kotler at imgtec.com <mailto:reed.kotler at

Hi David, Is there a reason that we need to have "final" for parser<bool> ??? This breaks the compilation of mclinker which derives a class from this. In file included from /home/rkotler/workspace/mclinker/lib/Support/CommandLine.cpp:9:0: /home/rkotler/workspace/mclinker/include/mcld/Support/CommandLine.h:49:7: error: cannot derive from ‘final’ base

According to the TableGen manual: "Each def record has a special entry called "NAME." This is the name of the def ("ADD32rr" above). In the general case def names can be formed from various kinds of string processing expressions and NAME resolves to the final value obtained after resolving all of those expressions. The user may refer to NAME anywhere she desires to

On 12/15/2012 12:53 PM, Chandler Carruth wrote: > On Sat, Dec 15, 2012 at 12:33 PM, Reed Kotler <rkotler at mips.com > <mailto:rkotler at mips.com>> wrote: > > I have an approved target independent putback and i've run all > that we have at Mips as well as on x86 " make TEST=simple" > > Is there anything else that is easy to run that I

Hi: This is my first patch submission. Hopefully, this is the proper the protocol. Attached is a patch for the llc ARM backend: Added mechanism to generate switch table in a data section rather than having it interleaved with the code. This is controlled by command line flags and off by default. Also, tried to document and improve the code where I modified it. Robert -------------- next part

On 07/16/2013 06:01 PM, Reed Kotler wrote: > The Eclipse indexer seems to get stuck in the Clang unittests/AST > In Eclipse you can tell it that a given directory is derived, and then it won't try and index it. Probably the more complex clang tests are too involved for the indexer. >>> Hope this helps :) >>> >>> Regards, >>> >>> Tilmann

Hi Reed, On Jul 17, 2013, at 3:19 AM, Reed Kotler <rkotler at mips.com> wrote: > On 07/16/2013 06:01 PM, Reed Kotler wrote: >> The Eclipse indexer seems to get stuck in the Clang unittests/AST >> > > In Eclipse you can tell it that a given directory is derived, and then it won't try and index it. > > Probably the more complex clang tests are too involved

There are a lot of issues. For one, the function I'm compiling is a mips16 function but the stubs being created are mips32 functions. On 04/24/2013 03:25 PM, Rafael Espíndola wrote: > compiler generated inline assembly looks odd. What is it that prevents > the llvm backend from printing the assembly you need for the stubs? > > On 24 April 2013 17:58, reed kotler <rkotler at

I'm getting this error in my mips16 port. I think that PHI replacement is done in some target independent phase. In the process of debugging this. Maybe to someone else it's obvious how this can happen . tia, Reed *** Bad machine code: MBB exits via unconditional fall-through but its successor differs from its CFG successor! *** - function: main - basic block: BB#0 entry

We are considering running clang format on the whole Mips target. Is there any rule against this? Is there any good argument against doing this even if there is no rule against it? TIA. Reed

Seems to just be a byproduct of TGParser::AddSubClass() begin called twice. This means that TGParser::AddValue() is being called once for the "i" of each class, and the "last one wins". Not sure if it is intended, but this behavior seems to more-or-less "make sense". --Sean Silva On Mon, Jul 2, 2012 at 4:55 PM, reed kotler <rkotler at mips.com> wrote: >

class one { int i = 0; } class two { int i = 1; } class multiple: one, two; This causes the first i to be ignored and the second i to replace it. This is a useful property if you want to specialize classes. But I don't know if it was intended to work that way or not. For example, if you have an instruction class with no patterns, you can merge it with one that defines the pattern

compiler generated inline assembly looks odd. What is it that prevents the llvm backend from printing the assembly you need for the stubs? On 24 April 2013 17:58, reed kotler <rkotler at mips.com> wrote: > When the compiler emits assembly code in gcc, there is no #APP/#NOAPP > > In my case, I'm creating inline assembly IR as part of the compilation > process (not user

When the compiler emits assembly code in gcc, there is no #APP/#NOAPP In my case, I'm creating inline assembly IR as part of the compilation process (not user supplied). These are for compiler generated stubs. So I'm seeing these #APP,#NOAPP wrappers which are meant for user inline assembly. Since I'm generating a lot of inline assembly and then each line is enclosed by this