On 11-06-02 6:56 AM, Anton Korobeynikov wrote:> Hi Chip, > >> Because of all this, it's hard to reconstruct the SEH information from >> the MachineMove array. I have thought about adding a new array specific >> to SEH information, but I'm not sure how you guys would feel about that. >> Any ideas on how to solve this problem? > Same problem with ARM-specific EH. I ended with own information > scheme, where instructions are marked as "frame related" during all > prologue& epilogue emission and later are "recognized" during the MI > => MCInst lowering. You might want to look into ARM backend, maybe we > can somehow "generalize" this approach. >Yes, the current model of producing a on the side vector of machine moves doesn't look like the best thing to do now that we produce cfi directives. I was thinking about just creating pseudo instructions that map 1:1 to the cfi directives (and ARM, and SEH). Codegen would create the appropriate one depending on the target. This would also avoid the silly labels that we still create when producing cfi. Cheers, Rafael
On Jun 2, 2011, at 6:20 AM, Rafael Ávila de Espíndola wrote:> On 11-06-02 6:56 AM, Anton Korobeynikov wrote: >> Hi Chip, >> >>> Because of all this, it's hard to reconstruct the SEH information from >>> the MachineMove array. I have thought about adding a new array specific >>> to SEH information, but I'm not sure how you guys would feel about that. >>> Any ideas on how to solve this problem? >> Same problem with ARM-specific EH. I ended with own information >> scheme, where instructions are marked as "frame related" during all >> prologue& epilogue emission and later are "recognized" during the MI >> => MCInst lowering. You might want to look into ARM backend, maybe we >> can somehow "generalize" this approach. >> > > Yes, the current model of producing a on the side vector of machine > moves doesn't look like the best thing to do now that we produce cfi > directives. > > I was thinking about just creating pseudo instructions that map 1:1 to > the cfi directives (and ARM, and SEH). Codegen would create the > appropriate one depending on the target. This would also avoid the silly > labels that we still create when producing cfi.+1 - Devang
On Jun 2, 2011, at 6:20 AM, Rafael Ávila de Espíndola wrote:> On 11-06-02 6:56 AM, Anton Korobeynikov wrote: >> Hi Chip, >> >>> Because of all this, it's hard to reconstruct the SEH information from >>> the MachineMove array. I have thought about adding a new array specific >>> to SEH information, but I'm not sure how you guys would feel about that. >>> Any ideas on how to solve this problem? >> Same problem with ARM-specific EH. I ended with own information >> scheme, where instructions are marked as "frame related" during all >> prologue& epilogue emission and later are "recognized" during the MI >> => MCInst lowering. You might want to look into ARM backend, maybe we >> can somehow "generalize" this approach. >> > > Yes, the current model of producing a on the side vector of machine > moves doesn't look like the best thing to do now that we produce cfi > directives. > > I was thinking about just creating pseudo instructions that map 1:1 to > the cfi directives (and ARM, and SEH). Codegen would create the > appropriate one depending on the target. This would also avoid the silly > labels that we still create when producing cfi. >Pseudo instructions are problematic. That means every function pass that iterates over the instructions has to explicitly check for them to make sure they don't affect optimization. We already have to do that for debug_value instructions, and it's really unpleasant and error prone. -Jim
> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Jim Grosbach > Sent: Thursday, June 02, 2011 9:11 AM > To: Rafael Ávila de Espíndola > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Advice on MachineMoves and SEH > > > On Jun 2, 2011, at 6:20 AM, Rafael Ávila de Espíndola wrote: > > > On 11-06-02 6:56 AM, Anton Korobeynikov wrote: > >> Hi Chip, > >> > >>> Because of all this, it's hard to reconstruct the SEH information > from > >>> the MachineMove array. I have thought about adding a new array > specific > >>> to SEH information, but I'm not sure how you guys would feel about > that. > >>> Any ideas on how to solve this problem? > >> Same problem with ARM-specific EH. I ended with own information > >> scheme, where instructions are marked as "frame related" during all > >> prologue& epilogue emission and later are "recognized" during the > MI > >> => MCInst lowering. You might want to look into ARM backend, maybe > we > >> can somehow "generalize" this approach. > >> > > > > Yes, the current model of producing a on the side vector of machine > > moves doesn't look like the best thing to do now that we produce cfi > > directives. > > > > I was thinking about just creating pseudo instructions that map 1:1 > to > > the cfi directives (and ARM, and SEH). Codegen would create the > > appropriate one depending on the target. This would also avoid the > silly > > labels that we still create when producing cfi. > > > > Pseudo instructions are problematic. That means every function pass > that iterates over the instructions has to explicitly check for them to > make sure they don't affect optimization. We already have to do that > for debug_value instructions, and it's really unpleasant and error > prone.[Villmow, Micah] What about adding a field to the Instruction class that specifies if it is a pseudo instruction or not. That way it is the same check no matter how many pseudo-instructions are added. While this might not be the best solution, if it is something that has to be done for debug_value instructions already, and no better solution is proposed, it might be helpful.> > -Jim > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Jun 2, 2011, at 9:11 AM, Jim Grosbach wrote:> > On Jun 2, 2011, at 6:20 AM, Rafael Ávila de Espíndola wrote: > >> On 11-06-02 6:56 AM, Anton Korobeynikov wrote: >>> Hi Chip, >>> >>>> Because of all this, it's hard to reconstruct the SEH information from >>>> the MachineMove array. I have thought about adding a new array specific >>>> to SEH information, but I'm not sure how you guys would feel about that. >>>> Any ideas on how to solve this problem? >>> Same problem with ARM-specific EH. I ended with own information >>> scheme, where instructions are marked as "frame related" during all >>> prologue& epilogue emission and later are "recognized" during the MI >>> => MCInst lowering. You might want to look into ARM backend, maybe we >>> can somehow "generalize" this approach. >>> >> >> Yes, the current model of producing a on the side vector of machine >> moves doesn't look like the best thing to do now that we produce cfi >> directives. >> >> I was thinking about just creating pseudo instructions that map 1:1 to >> the cfi directives (and ARM, and SEH). Codegen would create the >> appropriate one depending on the target. This would also avoid the silly >> labels that we still create when producing cfi. >> > > Pseudo instructions are problematic. That means every function pass that iterates over the instructions has to explicitly check for them to make sure they don't affect optimization. We already have to do that for debug_value instructions, and it's really unpleasant and error prone.How many passes are there this late in chain ? In any case, they all know how to deal with PROLOG_LABEL anyway. Personally, I'd like to make dwarf writer free of MachineModuleInfo. - Devang