[llvm] r195067 - [Mips] Support for MicroMips STO refactoring.

[Jack Carter]

I can revert it, but it changes nothing.

You asked me to do the refactoring first and this is part of it. The warning introduction was because my refactoring was not complete and that is regrettable, but should not be the reason for a revert.

Only AsmPrinter was able to use it before and all I did was to remove the dummy directive that was put in for test purposes. 

Yes, we need to have STO support in AsmParser, but the reality is that it isn't there now and was not there before.

I will revert it.

Jack
________________________________________
From: Rafael Espíndola [rafael.espindola at gmail.com]
Sent: Monday, November 18, 2013 10:07 PM
To: Jack Carter
Cc: llvm-commits
Subject: Re: [llvm] r195067 - [Mips] Support for MicroMips STO refactoring.

> [Mips] Support for MicroMips STO refactoring.
>
> No true functional changes.
>
> Change the "hack" name of emitMipsHackSTOCG to emitSymSTO.
>
> Remove demonstration code in AsmParser for emitMipsHackSTOCG and
> emitMipsHackELFFlags. The STO field is in an ELF symbol and is not
> an explicit directive. That said, we are missing the compliment call
> in AsmParser and that will need to be addressed soon.


This is a really bad change. The existing asm support was a hack, but
this worse. Right now emitSymSTO is an object file emission only
feature. The asm streamer is a nop.

Reiterating one more time: The entire idea of having the streamer
interface is that printing assembly and reading it back produces the
same output. This is obviously not the case right now with emitSymSTO
being a nop. This is as bad as having an if on the output being an
object file or assembly.

Also, this was not reviewed and introduce warnings in the build that
Eric fixed in followup.

Please revert this. Lets make sure that in every step along the way we
are always able to print assembly and read it back in.

Cheers,
Rafael