<commit_before>//===---------------------------------------------------------------------===//
// Random ideas for the X86 backend.
//===---------------------------------------------------------------------===//


//===---------------------------------------------------------------------===//

CodeGen/X86/lea-3.ll:test3 should be a single LEA, not a shift/move.  The X86
backend knows how to three-addressify this shift, but it appears the register
allocator isn't even asking it to do so in this case.  We should investigate
why this isn't happening, it could have significant impact on other important
cases for X86 as well.

//===---------------------------------------------------------------------===//

This should be one DIV/IDIV instruction, not a libcall:

unsigned test(unsigned long long X, unsigned Y) {
        return X/Y;
}

This can be done trivially with a custom legalizer.  What about overflow 
though?  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14224

//===---------------------------------------------------------------------===//

Improvements to the multiply -> shift/add algorithm:
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01590.html

//===---------------------------------------------------------------------===//

Improve code like this (occurs fairly frequently, e.g. in LLVM):
long long foo(int x) { return 1LL << x; }

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01109.html<commit_msg>we should eventually add -march=atom and the new atom movbe instruction.<commit_after>//===---------------------------------------------------------------------===//
// Random ideas for the X86 backend.
//===---------------------------------------------------------------------===//

We should add support for the "movbe" instruction, which does a byte-swapping
copy (3-addr bswap + memory support?)  This is available on Atom processors.

//===---------------------------------------------------------------------===//

CodeGen/X86/lea-3.ll:test3 should be a single LEA, not a shift/move.  The X86
backend knows how to three-addressify this shift, but it appears the register
allocator isn't even asking it to do so in this case.  We should investigate
why this isn't happening, it could have significant impact on other important
cases for X86 as well.

//===---------------------------------------------------------------------===//

This should be one DIV/IDIV instruction, not a libcall:

unsigned test(unsigned long long X, unsigned Y) {
        return X/Y;
}

This can be done trivially with a custom legalizer.  What about overflow 
though?  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14224

//===---------------------------------------------------------------------===//

Improvements to the multiply -> shift/add algorithm:
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01590.html

//===---------------------------------------------------------------------===//

Improve code like this (occurs fairly frequently, e.g. in LLVM):
long long foo(int x) { return 1LL << x; }

http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01109.html
{'fraction_non_alphanumeric': 0.36919555264879006, 'fraction_numerical': 0.025179856115107913, 'mean_word_length': 1.315669947009841, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6580319', 'n_tokens_mistral': 804, 'n_tokens_neox': 729, 'n_words': 268}