search for: nocmov

...x C++ code? There are too many static predicates, so it isn't feasible to enumerate all possible combinations, but we can expose their relationships to the tool as boolean expressions. For example, X86 currently has: def HasCMov : Predicate<"Subtarget->hasCMov()">; def NoCMov : Predicate<"!Subtarget->hasCMov()">; It would be simple to define: def NoCMov : Predicate<(not HasCMov)>; And the tool would be able to infer that the predicates are disjoint. Similarly: def : Always<(or HasSSE1, (not HasSSE2))>; can be used to infer...

>>> I like the idea of sharing code between IR and MI passes through an >>> abstract interface. I think that later stages in the IR pipeline also >>> need an instruction optimizer instead of a canonicalizer. >>> >>> An alternative approach would be to describe these transformations in a >>> DSL instead of C++. >> >>>

On Aug 10, 2013, at 7:32 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: >> I like the idea of sharing code between IR and MI passes through an abstract interface. I think that later stages in the IR pipeline also need an instruction optimizer instead of a canonicalizer. >> >> An alternative approach would be to describe these transformations in a DSL instead of C++. >

On Feb 22, 2011, at 6:46 PM, Chris Lattner wrote: > This leads to a number of problems in LLVM: > - we have a bunch of duplication > - we have confusion about what a triple is (normalized or not) > - no good way to tell if a triple is normalized > - no good, centralized way to reason about which triples are allowed and valid > - the MC assembler has to link in the entire X86

Hi All, There is recently a discussion on the LLDB list about how to deal with targets, and our current mismash of llvm::Triple and the various subclasses of TargetSubtarget leave a lot to be desired. GNU target triples are really important as input devices to the compiler (users want to specify them) but they aren't detailed enough for internal clients. Anyway, in short, I think that we