similar to: [LLVMdev] Modifying DAG in TargetLowering::ReplaceNodeResults()

First off, I would like to express my appreciation for the tinc software, it has been such a great vpn solution for what i need, its amazing. I am setting up another node on the vpn. "KVM" is my public facing node, "MacbookAir" is my workstation, "NewNode" is my node i have recently configured and the one with the issue presumably. NewNode and MacbookAir are on the

Hi, I see that for different targets in classes which inherits from TargetLowering there are implemented both methods: LowerOperation and ReplaceNodeResults What decides that for one given ISD we have to add handling in LowerOperation and for other in ReplaceNodeResults, when for both SetOperationAction is configured to be Custom? Is it related with number of results of given operation and

Thank you Craig for explanation. Could be the same algorithm used for custom legalizing given node in LowerOperation and ReplaceNodeResults in case results and inputs of the node are illegal? Or actually such situation is impossible and for given node either LowerOperation or ReplaceNodeResults can be only called? Przemek wt., 28 sty 2020, 18:48 użytkownik Craig Topper <craig.topper at

Hi, I've discovered a problem on Sparc processors (specifically, LEON, but I suspect but can't verify that it also happens on all Sparc processors). The problem is, or appears to be with using double values in Sparc (32 bit). Specifically, double values are not being loaded into registers correctly within a function using va_args. Only half the value is loaded (i.e. 32, rather than 64

Hi All , Was trying to build the LLVM src from http://llvm.org/svn/llvm-project/llvm/branches/release_30 ,But unable to build the same and clang poped up with below error . llvm[1]: Compiling IntervalMap.cpp for Debug build In file included from /root/projects/safecode/llvm/lib/Support/IntervalMap.cpp:14: /root/projects/safecode/llvm/include/llvm/ADT/IntervalMap.h:1980:32: error: use

Hello, I''m configuring my linux server with puppet open and is ok. My question is the next; I''ve a declared in mi nodes.pp the next: [.............] node ''basenode'' { include ''baseos'' include ''motd'' import ''useradd.pp'' } #All nodes for my domain node /.*\.example\.com/ inherits

On Mon, May 14, 2012 at 4:39 PM, John Criswell <criswell at illinois.edu>wrote: > On 5/14/12 4:32 AM, Umesh Kalappa wrote: > > Hi All , > > Was trying to build the LLVM src from > http://llvm.org/svn/llvm-project/llvm/branches/release_30 ,But unable to > build the same and clang poped up with below error . > > > First, it sounds like you're building LLVM

On 5/14/12 4:32 AM, Umesh Kalappa wrote: > Hi All , > > Was trying to build the LLVM src from > http://llvm.org/svn/llvm-project/llvm/branches/release_30 ,But unable > to build the same and clang poped up with below error . First, it sounds like you're building LLVM 3.0, Poolalloc, and SAFECode with an unmodified version of clang. Is this correct? If so, which version of

Hi, If you are familiar with LegalizeTypes I will be glad if you can help me with the following scenario. I'm debugging some ll test that fails with an assertion in "void DAGTypeLegalizer::RemapValue(SDValue &N)" because it does not expect that a remap to a new node exists. However looking at the code for a while this seems to be a valid case. I see that many times nodes are

Thank you all for the responses, John, My Bad here you go clang version 3.2 (trunk) Target: i386-pc-linux-gnu Thread model: posix [root at localhost opensrc]# cat /etc/centos-release CentOS release 6.2 (Final) Matthieu, Thanks for the fix and let me try again with latest trunk. ~Umesh On Mon, May 14, 2012 at 10:34 PM, Matthieu Monrocq <

# The future of the va_arg instruction ## Summary LLVM IR currently defines a va_arg instruction, which can be used to access a vararg. Few Clang targets make use of it, and it has a number of limitations. This RFC hopes to promote discussion on its future - how 'smart' should va_arg be? Should we be aiming to transition all targets and LLVM frontends to using it? ## Background on va_arg

On 9 August 2017 at 19:38, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/9/2017 9:11 AM, Alex Bradbury via llvm-dev wrote: >> >> Option 3: Teach va_arg to handle aggregates >> * In this option, va_arg might reasonably be expected to handle a >> struct, >> but would not be expected to have detailed ABI-specific knowledge. e.g. >> it

Hi everyone, I'm interested in variadic functions and how llvm handles them. I discovered that the Clang frontend is doing a great job at lowering the va_arg (precisely __builtin_va_arg) function into target dependent code. I have also seen the va_arg function that exist at IR level. I found some information about va_arg (IR one) that currently does not support all platform. But since 2009,

The intrinsic ID is an int, not a float. —escha > On Jun 24, 2016, at 7:49 AM, Ryan Taylor via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > given the following C code: > > float b=16, a=0; > int main() { > float a = sqrt(b); > return0; > } > > I'm trying to lower FSQRT down, but getting a casting issue, my code is: > > SDValue

hi all i see a very strange behavior in safari when using prototype.js and the pear HTML_TreeMenu to reproduce get prototype.js (http://www.prototypejs.org/assets/ 2008/1/25/prototype-1.6.0.2.js) and treemenu.js (http://cvs.php.net/ viewvc.cgi/pear/HTML_TreeMenu/TreeMenu.js?revision=1.22). and test the following html with safari on mac or windows (http:// www.apple.com/safari/download/)

Hi folk, I'm writing a set of small C code to verify whether my pass handle some instruction correctly. One of the instruction I want to test is "va_arg", but compiling my variadic function does not generate any va_arg instruction. Is va_arg deprecated? Will va_arg instruction ever be generated by any front-end? The source code and llvm instructions are appended as follows. the

Neal, FYI, my group has added a flag to llvm-gcc for emitting the va_arg instruction (instead of lowering in the front-end), and we also have an implementation of the VAARG instruction for X86-64. (which is currently not implemented in the LLVM backend). Both of these things will be sent upstream to LLVM soon, pending some more testing and review. If you are dire need of these features now, I

I was reading the code in AliasAnalysis.cpp and happened to notice what looks like a bug. See the line marked by '*' below: AliasAnalysis::ModRefResult AliasAnalysis::getModRefInfo(const VAArgInst *V, const Location &Loc) { // If the va_arg address cannot alias the pointer in question, then the // specified memory cannot be accessed by the va_arg. if (!alias(getLocation(V),

I've tried all the types (both for result and Intrinsic ID), can't seem to find what cast is causing the issue here. On Fri, Jun 24, 2016 at 11:47 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > That's what I thought but I got the same error with: > > DAG.getNode(ISD::INTRINSIC_WO_CHAIN, DL, VT, > DAG.getTargetConstant(Intrinsic::my_intrinsic, DL, MVT::i16), LHS);

I should have been more specific: "Why do we want this as an option? Do we want it on all the time? Why or why not?" -eric On Aug 17, 2011, at 3:02 PM, Will Dietz wrote: > To get clang to emit va_arg instructions for va_arg() calls, as > opposed to manually lowering it in the frontend, same as the llvm-gcc > patch sent earlier does. > > ~Will > > On Wed, Aug