From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754257AbbHFDW1 (ORCPT ); Wed, 5 Aug 2015 23:22:27 -0400 Received: from mail-pd0-f170.google.com ([209.85.192.170]:33867 "EHLO mail-pd0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752637AbbHFDW0 (ORCPT ); Wed, 5 Aug 2015 23:22:26 -0400 Date: Wed, 5 Aug 2015 20:22:22 -0700 From: Alexei Starovoitov To: "Wangnan (F)" Cc: Alexei Starovoitov , He Kuang , pi3orama , llvm-dev@lists.llvm.org, "linux-kernel@vger.kernel.org" Subject: Re: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event Message-ID: <20150806032221.GA52057@Alexeis-MBP.westell.com> References: <55B89F04.5030304@huawei.com> <55B909B2.2080606@plumgrid.com> <55BB4B8A.5000207@huawei.com> <55BFC4A0.9060100@plumgrid.com> <55C07F5B.6030107@huawei.com> <55C16DC7.70408@huawei.com> <55C16F53.3070604@huawei.com> <55C1B254.5030801@huawei.com> <55C1B717.60501@plumgrid.com> <55C1C91D.5080007@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C1C91D.5080007@huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 05, 2015 at 04:28:13PM +0800, Wangnan (F) wrote: > > It doesn't work for me at first since in my llvm there's only > llvm.bpf.load.*. > > I think llvm.bpf.store.* belone to some patches you haven't posted yet? nope. only loads have special instructions ld_abs/ld_ind which are represented by these intrinsics. stores, so far, are done via single bpf_store_bytes() helper function. > >the typeid changing ids with order is surprising. > >I think the assertion in ExtractTypeInfo() is not hard. > >Just there were no such use cases. May be we can do something > >similar to what LowerIntrinsicCall() does and lower it differently > >in the backend. > > > But in backend can we still get type information? I thought type is > meaningful in frontend only, and backend behaviors is unable to affect > DWARF generation, right? why do we need to affect type generation? we just need to know dwarf type id in the backend, so we can emit it as a constant. I still think lowering eh_typeid_for differently may work. Like instead of doing GV = ExtractTypeInfo(I.getArgOperand(0)) followed by getMachineFunction().getMMI().getTypeIDFor(GV) we can get dwarf type id from I.getArgOperand(0) if it's any pointer to struct type. I'm not familiar with dwarf handling part of llvm, but feels possible.