<div dir="ltr"><div dir="ltr">On Mon, Feb 18, 2019 at 9:47 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I think it would be a shame to lose the ability to run opt and clang -S -emit-llvm for a target without compiling in the target's code generator.</div></blockquote><div><br></div><div>Currently, identical inputs and command line options to `opt` and `clang` will produce *different outputs* based on whether a target happened to be compiled in at build time. That seems worse to me than producing an error?</div></div></div></blockquote><div><br></div><div>Doesn't that really only matter if a full pass pipeline gets built, i.e. opt/clang -O2? Most well-behaved clang and opt tests use -disable-llvm-passes or `opt -pass=mypass`, and they don't require a TargetMachine to run. Perhaps we could diagnose an error if the TargetMachine would be used to build the pipeline. Basically, move the null check and error to the point of usage.</div><div><br></div><div>I feel like this gives us some incremental value of being able to disable some backends for build time or code size reasons while still being able to run IR generation and transformation tests that happen to use that triple.</div></div></div>