search for: getoptimalmemoptype

Hi John, On Tue, 14 May 2019 at 17:51, Joan Lluch <joan.lluch at icloud.com> wrote: > This problem is also shared by the MSP430 target, and it’s very easy to reproduce by just compiling the code that I posted before. That's some good detective work; it definitely explains what you're seeing. Since MSP430 is affected it would probably be pretty easy to upstream an alignment-aware

Hi Joan, On Mon, 13 May 2019 at 18:01, Joan Lluch <joan.lluch at icloud.com> wrote: > After looking at it a bit further, I think this is a Clang thing. Clang issues “align 2” if the struct has at least one int (2 bytes), but also if the entire struct size is multiple of 2. For example a struct with 4 char members. In these cases the LLVM backend correctly creates word sized load/stores

Hi, For my 32-bit architecture backend, I run into trouble because strcpy is converted into i64 store instructions, on which instruction selection fails. No i64 store is declared anywhere in my .td files or architecture backend, so I would assume that they are automatically converted into 2 i32 stores, but apparently, that is not the case. Do I need to add anything to my backend to have this

...sounds like a bug worth filing. > > Lowering of memcpy is affected by the size of the copy, alignments of > the source and dest, and CPU target. You may be able to narrow down > the problem by changing those parameters. > The relevant target-specific logic is in X86TargetLowering::getOptimalMemOpType, looking at that might help in understanding what's going on. -Hal > > On Tue, Nov 3, 2015 at 11:01 AM, Jay McCarthy < > jay.mccarthy at gmail.com > wrote: > > > Thank you for your reply. FWIW, I wrote the .ll by hand after taking > the C program, using clang to...

...g of memcpy is affected by the size of the copy, alignments of > >> the source and dest, and CPU target. You may be able to narrow down > >> the problem by changing those parameters. > >> > > > > The relevant target-specific logic is in > X86TargetLowering::getOptimalMemOpType, looking at that might help in > understanding what's going on. > > > > -Hal > > > >> > >> On Tue, Nov 3, 2015 at 11:01 AM, Jay McCarthy < > >> jay.mccarthy at gmail.com > wrote: > >> > >> > >> Thank you for your...

...39;t implemented O32/N32 yet. * MemorySanitizer: Is heading down the same road but hasn't implemented O32/N32 yet. * Many places where hasMips64*() or isGP64bit() are used in the backend. * MSA intrinsic lowering * Legalization configuration * Instruction selection * MipsTargetLowering::getOptimalMemOpType() * And many more. I can provide more detail if you want. Other notables: * RuntimeDyldELF gets it right but only because it can read the ELF headers instead of the Triple. It went down the same road for a while. I'll provide a CodeGen example tomorrow if you want. ________________________...

...39;t implemented O32/N32 yet. * MemorySanitizer: Is heading down the same road but hasn't implemented O32/N32 yet. * Many places where hasMips64*() or isGP64bit() are used in the backend. * MSA intrinsic lowering * Legalization configuration * Instruction selection * MipsTargetLowering::getOptimalMemOpType() * And many more. I can provide more detail if you want. Other notables: * RuntimeDyldELF gets it right but only because it can read the ELF headers instead of the Triple. It went down the same road for a while. I'll provide a CodeGen example tomorrow if you want. _______________________...

...39;t implemented O32/N32 yet. * MemorySanitizer: Is heading down the same road but hasn't implemented O32/N32 yet. * Many places where hasMips64*() or isGP64bit() are used in the backend. * MSA intrinsic lowering * Legalization configuration * Instruction selection * MipsTargetLowering::getOptimalMemOpType() * And many more. I can provide more detail if you want. Other notables: * RuntimeDyldELF gets it right but only because it can read the ELF headers instead of the Triple. It went down the same road for a while. I'll provide a CodeGen example tomorrow if you want. _______________________...

...32 yet. · MemorySanitizer: Is heading down the same road but hasn't implemented O32/N32 yet. · Many places where hasMips64*() or isGP64bit() are used in the backend. o MSA intrinsic lowering o Legalization configuration o Instruction selection o MipsTargetLowering::getOptimalMemOpType() o And many more. I can provide more detail if you want. Other notables: · RuntimeDyldELF gets it right but only because it can read the ELF headers instead of the Triple. It went down the same road for a while. I'll provide a CodeGen example tomorrow if you want. I'd intende...

Thank you for your reply. FWIW, I wrote the .ll by hand after taking the C program, using clang to emit the llvm and seeing the memcpy. The memcpy version that clang generates gets compiled into assembly that uses the large sequence of movs and does not use the vector hardware at all. When I started debugging, I took that clang produced .ll and started to write it different ways trying to get

...39;t implemented O32/N32 yet. * MemorySanitizer: Is heading down the same road but hasn't implemented O32/N32 yet. * Many places where hasMips64*() or isGP64bit() are used in the backend. * MSA intrinsic lowering * Legalization configuration * Instruction selection * MipsTargetLowering::getOptimalMemOpType() * And many more. I can provide more detail if you want. Other notables: * RuntimeDyldELF gets it right but only because it can read the ELF headers instead of the Triple. It went down the same road for a while. I'll provide a CodeGen example tomorrow if you want. ________________________...

...32 yet. • MemorySanitizer: Is heading down the same road but hasn't implemented O32/N32 yet. • Many places where hasMips64*() or isGP64bit() are used in the backend. o MSA intrinsic lowering o Legalization configuration o Instruction selection o MipsTargetLowering::getOptimalMemOpType() o And many more. I can provide more detail if you want. Other notables: • RuntimeDyldELF gets it right but only because it can read the ELF headers instead of the Triple. It went down the same road for a while. I'll provide a CodeGen example tomorrow if you want. I'd intende...

>> Here's the line of thought that I'd like people to start with: >> * Triples don't describe the target. They look like they should, but they >> don't. They're really just arbitrary strings. > >Triples are used as a starting point, but no more. I disagree with this but for now let's assume it's true. The starting point is incorrect because