[llvm] r181753 - This is the first of three patches which creates stubs used for

[Eric Christopher]

>>> This pass is a self contained module pass which solves a very messy
>>> problem
>>> in mips16 in a very clear way. There are many cases to this and pic and
>>> static have some very different issues and there are endian issues too.
>>> In
>>> addition I have to change instruction sets because the code is being
>>> compiled for mips16 but the stubs are mips32 code.
>>
>> I'm not sure that this is an issue. Why is this a problem for you?
>>
> It's not a problem but it was very clear and easy to do in IR and I cannot
> say it would be like that later on in the compilation path.
>

Again, Going to point at the responses you've gotten from Jim and I on
this subject.

> People are told not to submit large patches so I did not even consider that
> option.

A pass is not a large patch.

> Is it necessary to do this other kind of alternate testing right now before
> checking in the rest?

You should, yes.

>
> I already have tests for checking that the assembly code is correct in the
> stubs. That is what I'm generating and that is what I want to verify.
>

But the compiler is not single pass. Especially since this seems
trivial to check just the output of your pass.

> Can I file a fixme bug against myself for this?
>
> If we do decide to move the inline assembly later in the compilation path,
> then the testing for assembly would still apply but not for just testing IR.
>
> It would be possible dump the IR I guess and look at it.
> Is this what you are asking?
>

Yes. Just run opt -my-pass I believe.

> I have not done that kind of test in past for LLVM.
>

Welcome to the IR level. You'll notice a lot of tests that do exactly this. :)

-eric