similar to: MachineVerifier and undef

Hello Thanks for looking into this. I can't be very confident what the knock on result of a change like that would be, especially on architectures that are not Arm. What I can do though, is run some benchmarks and look at that results. Using this patch: --- a/lib/Transforms/InstCombine/InstructionCombining.cpp +++ b/lib/Transforms/InstCombine/InstructionCombining.cpp @@ -150,6 +150,9 @@

Thanks for the perf testing. I assume that DAG legalization is equipped to handle these cases fairly well, or someone would've complained by now... FWIW (and at least some of this can be blamed on me), instcombine already does the narrowing transforms without checking shouldChangeType() for binops like and/or/xor/udiv. The justification was that narrower ops are always better for

Example: define i8 @narrow_add(i8 %x, i8 %y) { %x32 = zext i8 %x to i32 %y32 = zext i8 %y to i32 %add = add nsw i32 %x32, %y32 %tr = trunc i32 %add to i8 ret i8 %tr } With no data-layout or with an x86 target where 8-bit integer is in the data-layout, we reduce to: $ ./opt -instcombine narrowadd.ll -S define i8 @narrow_add(i8 %x, i8 %y) { %add = add i8 %x, %y ret i8 %add } But on

Hi everyone, I have an idea that should allow reducing code duplication in Casting.h while making llvm::isa, llvm::cast, llvm::dyn_cast, etc more generic. Since we added unique pointers support for these template functions (see ab480f45cd23c08cb9aa3f427aad072df249135f) I propose to generalize their semantics to deal with any pointer-like type (i.e. dereferenceable and implicitly convertible to

Looks pretty reasonable to me - with test cases. (not sure if dereferenced_type should be defined for a type that's not dereferenceable, though?) On Tue, Jan 23, 2018 at 7:02 AM Dmitriy Borisenkov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi everyone, > > I have an idea that should allow reducing code duplication in Casting.h > while making llvm::isa, llvm::cast,

Hi all, I have two questions about reading PDB file. For `llvm::pdb::loadDataFromEXE(PDB_ReaderType Type, ...)`, there are two places calling this method, `LLVMSymbolizer::getOrCreateModuleInfo(PDB_ReaderType::DIA, ...)`, see https://github.com/llvm-mirror/llvm/blob/master/lib/DebugInfo/Symbolize/Symbolize.cpp#L403, and `SymbolFilePDB::CalculateAbilities(PDB_ReaderType::DIA, ...)`, see

Hi Björn and Daniel, FoldPHIArgOpIntoPHI() is for unary ops (casts), but it calls FoldPHIArgBinOpIntoPHI() for binops which takes care of almost everything else? My minimal patch idea is to ease the restriction in ShouldChangeType because i1 is special. I tried the patch below, and it works on the example...and nothing in 'make check' failed. :) Index:

On Tue, Jan 31, 2017 at 3:09 AM, Björn Steinbrink <bsteinbr at gmail.com> wrote: > Hi Sanjay, > > 2017-01-30 22:22 GMT+01:00 Sanjay Patel <spatel at rotateright.com>: > >> My minimal patch idea is to ease the restriction in ShouldChangeType >> because i1 is special. I tried the patch below, and it works on the >> example...and nothing in 'make

Hi Sanjay, 2017-01-30 22:22 GMT+01:00 Sanjay Patel <spatel at rotateright.com>: > My minimal patch idea is to ease the restriction in ShouldChangeType > because i1 is special. I tried the patch below, and it works on the > example...and nothing in 'make check' failed. :) > Yeah, that would work for me as well, I just wasn't sure about the implications that has.

2017-01-31 16:59 GMT+01:00 Sanjay Patel <spatel at rotateright.com>: > > > On Tue, Jan 31, 2017 at 3:09 AM, Björn Steinbrink <bsteinbr at gmail.com> > wrote: > >> Hi Sanjay, >> >> 2017-01-30 22:22 GMT+01:00 Sanjay Patel <spatel at rotateright.com>: >> >>> My minimal patch idea is to ease the restriction in ShouldChangeType

Hi all, I've been investigating a machine verifier failure on the attached testcase, and I'm tempted to say the verifier is wrong and should accept it. Skip the description for the proposed change. On AArch64, the verifier complains with: *** Bad machine code: MBB exits via unconditional branch but doesn't have exactly one CFG successor! *** - function: t4 - basic

I'm working on getting an out of tree target machine verifier clean. This has found some nasty bugs so I'd like to continue with it. One instance of bad machine code is "Using an undefined physical register". This arises whenever undef propagates to a machine instruction. Usually this means the input was meaningless - e.g. call an undefined address. Other times it's a

Could we expose predicates defined in the target InstrInfo.td file to the MachineVerifier? We use BuildMI() to create many instructions after ISEL, but the predicates are not being checked at this point. Thus, I could forget to check the target and build an instruction that is illegal for a specific configuration. In such a case it would be nice if the MachineVerifier could detect this for me.

This is from https://stackoverflow.com/questions/48360685/no-targets-in-targetregistry I have the following code, which should get the default llvm::Target. auto const targetTriple = llvm::sys::getDefaultTargetTriple(); llvm_module.setTargetTriple(targetTriple); std::string error; auto const * target = llvm::TargetRegistry::lookupTarget(targetTriple, error); if (target ==

Hi, I'm part of an engineering team doing research on persistent memory support and we have stumbled upon an interesting problem. The issue is, we would like to be able to use the standard library containers in a persistent memory context (think NVDIMM-N). What I mean is that you allocate a container from said memory, use it like you normally would. After the application terminates, expectedly

On 09/17/2011 21:53, Eli Friedman wrote: > Yes; we don't make any sort of guarantee about that, and such a > guarantee is not necessary for correctness. Aren't values in Core.h supposed to be used by users of API and they should match enums, or what they are for then? What are they matched against? >> > Also, llvm/Support/TargetRegistry.h and

On Sat, Sep 17, 2011 at 9:14 PM, Yuri <yuri at rawbw.com> wrote: > Looks like constants in include/llvm-c/Core.h aren't in sync with enums. > For example, LLVMAdd is 8 in Core.h and  llvm::Instruction::LLVMAdd > evaluates to 9 in C++. > Same for Cast Operators section and possibly in other places. Yes; we don't make any sort of guarantee about that, and such a guarantee

Looks like constants in include/llvm-c/Core.h aren't in sync with enums. For example, LLVMAdd is 8 in Core.h and llvm::Instruction::LLVMAdd evaluates to 9 in C++. Same for Cast Operators section and possibly in other places. Also, llvm/Support/TargetRegistry.h and llvm/Target/TargetRegistry.h define two different version of some classes, particularly llvm::Target. Fields with the same

Hello, I am encountering a strange assertion failure using the LLVM libraries cross-compiled for Android using the Android NDK. I am using the official release of LLVM-2.9. The IR which is causing the assertion failure is the following: define void @__construct_Byte__Integer(i8* nocapture %byteLValue, i32 %integerRValue) inlinehint { entry: %0 = trunc i32 %integerRValue to i8 store i8 %0,

On Thu, Sep 8, 2011 at 12:12 AM, Max Kazakov <max.kazakov at gmail.com> wrote: > Hi, > > The code @ line 584 of TargetRegistry.h effectively suppresses specifying any > AsmStreamer constructor function but stock createAsmStreamer one. Is it by > intention or condition should be replaced with != ? Hi Max, are you sure that you have the tip-of-tree version of