search for: irorder

...ut it looks to be machine noise as I see both regressions and improvements in different benchmarks in different runs. I see +/- 0.5% in the unit tests, but that goes both ways. Both tests use release+asserts build. Your patch looks fine but doesn't go far enough. I'd like to add an IROrder field to SDNode (eventually we might be able to make it redundant with NodeId, although there would be temporary points at which nodes have to share an IROrder). That would remove any concerns about the compile-time of potentially frequent DenseMap lookup. But I really want to do it to help ensure...

Updating the subject line. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Gautam Chakrabarti via llvm-dev Sent: Wednesday, March 28, 2018 11:58 PM To: LLVM Dev <llvm-dev at lists.llvm.org> Subject: [llvm-dev] Why do constant SD nodes not set the IROrder? Specifically I would like to understand why ConstantSDNode and ConstantFPSDNode do not set the IR ordering like most other SDNode-s. These constant SD nodes also previously did not set the debugloc, but that got enabled (here: http://llvm.org/viewvc/llvm-project?view=revision&revision=237237)...

...ut it looks to be machine noise as I see both regressions and improvements in different benchmarks in different runs. I see +/- 0.5% in the unit tests, but that goes both ways. Both tests use release+asserts build. Your patch looks fine but doesn't go far enough. I'd like to add an IROrder field to SDNode (eventually we might be able to make it redundant with NodeId, although there would be temporary points at which nodes have to share an IROrder). That would remove any concerns about the compile-time of potentially frequent DenseMap lookup. But I really want to do it to help ensure...

Specifically I would like to understand why ConstantSDNode and ConstantFPSDNode do not set the IR ordering like most other SDNode-s. These constant SD nodes also previously did not set the debugloc, but that got enabled (here: http://llvm.org/viewvc/llvm-project?view=revision&revision=237237). These constant SD nodes hard-code the order to 0. Is this intentional, or just something that has

...as I see both regressions and improvements in different > benchmarks in different runs. I see +/- 0.5% in the unit tests, but that > goes both ways. Both tests use release+asserts build. > > > > Your patch looks fine but doesn't go far enough. I'd like to add an > IROrder field to SDNode (eventually we might be able to make it redundant > with NodeId, although there would be temporary points at which nodes have > to share an IROrder). That would remove any concerns about the compile-time > of potentially frequent DenseMap lookup. But I really want to do it...

...ise as I see both regressions and improvements in different benchmarks in different runs. I see +/- 0.5% in the unit tests, but that goes both ways. Both tests use release+asserts build. > > > > Your patch looks fine but doesn't go far enough. I'd like to add an IROrder field to SDNode (eventually we might be able to make it redundant with NodeId, although there would be temporary points at which nodes have to share an IROrder). That would remove any concerns about the compile-time of potentially frequent DenseMap lookup. But I really want to do it to help ensure...

...ency" (any better name?) Unfortunately, LLVM does not guarantee codegen consistency. Recently, I've spent quite some time try to fix related issues (e.g. https://reviews.llvm.org/D25286 and https://reviews.llvm.org/D25098). The most recent issue I'm looking at is that during isel, the IROrder is used by both debug info and the actual codegen, which is relative harder to fix. I initially thought that it's just a couple of careless bugs to fix. But looks like there are much more issues than I expected. So I'm calling the community for help: * Is there anyone else who also cares...

...tion which corresponds to MachineInstrs. If so, it's much easier to analyse IR Instructions instead of MachineInstrs. However, in the frame of LLVM 3.3, I can't find the corresponding(connected) information from Instruction to MachineInstrs in the CodeGenAndEmitDAG function. PS: I once used IROrder which is a member of class SDNode as unchangeable information, but it's roughly corresponding information, so the map <Instruction*, vector<MachineInstr*> > often overlaps. Could someone help me with that? Thank you very much in advance. -Haishan -------------- next part -----------...

...o, it's much easier >> to analyse IR Instructions instead of MachineInstrs. >> However, in the frame of LLVM 3.3, I can't find the corresponding(connected) >> information >> from Instruction to MachineInstrs in the CodeGenAndEmitDAG function. >> PS: I once used IROrder which is a member of class SDNode as unchangeable >> information, but it's roughly corresponding information, so the map >> <Instruction*, vector<MachineInstr*> > often overlaps. >> Could someone help me with that? >> Thank you very much in advance. >>...