[PATCH] Add warning capabilities in LLVM (backend part)

[Quentin Colombet]

  Hi Hal,

  Thanks for the feedback.
  I suggest that you read the RFC regarding the choices for the interface.
  What you are proposing has IIRC already been discussed.

  Let me try to summarize why we did not choose what you are proposing:
  1. srcloc metadata.
  We cannot anticipate what would be reported and in particular, a source location may not be adapted. Assume you want to report why the vectorizer failed to optimize a given loop. Having only one source location will not be enough. So why should we be bound to one source location?

  2. StringRef vs. ArrayRef<Value*>
  First I will quote David Blaikie and Chris Lattner on StringRef vs. ArrayRef<StringRef>:
  David: “Presumably there are diagnostics that are going to have more than one parameter, though. ArrayRef<StringRef>?”
  Chris: “It's possible, but the full generality of any diagnostic can be folded (at some loss of generality) into a single string.  To balance complexity and generality vs simplicity, "1" is a pretty decent number.”

  Now, why using StringRef instead of Value, I see two reasons for that:
  - I believe we do not want the diagnostic system of the front-end to have to deal with the IR.
  - What happens for a report coming for the MC level (e.g., AsmParser), IIRC, there is no Value involved here.

  3. Default message printer.
  The idea of the default message printer is to provide a directly usable message. I believe we do not what to push in every front-end a parsing of the default message. Moreover, like I said, I think we may not be able to produce Value objects every time.

  What do you think?

  Cheers,
  Quentin

http://llvm-reviews.chandlerc.com/D2190