search for: typein

Hi All, Renato wrote: >As they say: if it's not broken, don't fix it. >Let's talk about the reductions that AVX512 and SVE can't handle with IR semantics, but let's not change the current IR semantics for no reason. Main problem for SVE: We can't write straight-line IR instruction sequence for reduction last value compute, without knowing #elements in vector to

...e/inttypes.h:385: error: `__extern_inline' does not name a type/usr/include/inttypes.h:401: error: `__extern_inline' does not name a type/usr/includ! e/inttypes.h:415: error: `__extern_inline' does not name a type/usr/include/inttypes.h:432: error: `__extern_inline' does not name a typeIn file included from/home/wanghao/Desktop/SimIt-ARM-3.0/build/include/dyn_arm_emul.hpp:18, from /home/wanghao/.ema/u512//Xcompiled_0.cpp:2:/usr/include/pthread.h:1110: error: expected constructor, destructor, or typeconversion/usr/include/pthread.h:1110: error: expected `,' or `;&...

Hi, Renato. >So I vote "it depends". :) My preference is to let vectorizer emit one kind of "reduce vector into scalar" instead of letting vectorizer choose one of many different ways. I'm perfectly fine with @llvm.reduce.op.typein.typeout.ordered?(%vector) being that "one kind of reduce vector into scalar". I think we are converging enough at the detail level, but having a big difference in the opinions at the "vision" level. :) Thanks, Hideki -----Original Message----- From: Renato Golin [mailto:rena...